[DAS2] We need your input for DAS/2 spec freeze!

[Andrew Dalke]

Brian:
> 1) Best practices for namespacing? What will I encounter in the wild?  
> <das:blah> or <blah>. It would be good to let people know what the  
> DAS2 specification writers preferred from the implementing community.  
> I know if doesn't really matter from the spec writer point of view  
> but, from and engineers point of view it really does. Anything I can  
> do to reduce the number of chars I'm using in and XML document to save  
> overhead we will try and do.

I expect most will use the default namespace.  From "an engineer's  
point of view"
how does it make a difference?  Every XML parser has to understand  
either
case, plus the use of any other valid namespace prefix as an  
alternative.

To reduce the number of characters, use the default namespace and use
http request negotiation to compress the data stream.  Terseness was not
a design goal in DAS or DAS2.

> 2) Error codes: You have sprinkled error codes into the document for  
> what an implementor will send back to the caller. Would be wonderful  
> to have all error codes put into one place or at least put into a  
> little table so we know what to implement when there is an error  
> condition.

Those are the HTTP error codes.  See the HTTP spec for them.

Experience with DAS1 strongly suggests that another layer of response  
codes
does not work.  You end up needing to handle the HTTP response codes
plus the higher layer codes -- and in DAS1 you could even return the
error in the response XML.

None of the DAS1 clients did anything special with the error codes,
other than to report the error to the user.  So we decided in a meeting
some time ago to leave it at that.

>  Quick question on Features. Spec says, "Servers may respond with an  
> error if there are too many matching features to return." What error  
> shall I return here? Would be great to make all the errors explicit so  
> clients can either display the appropriate error message or recover  
> gracefully (latter being the most desirable outcome).

Depends on the problem and how it's identified.  Looking at RFC 2616
section 10 some of the likely ones are

500 - internal server error (eg, if your backend segfaults)
503 - if the server load is too high
504 - if you have a proxy forwarding to an internal server and the  
internal
    server takes too long
413 - Request Entity Too Large

DAS clients should follow the HTTP spec.

Nothing in DAS ended up needing an addition to the HTTP error codes.


> 3) For C/C++/Java programmers - it would be great to have a list of
> interfaces to code to that are business/institution agnostic - I'm
> planning on doing this so maybe put me on the hook for those? Would
> like some help with that though...

Since I don't know what that means I can't help.

> 4) One more plea for XML Schema! Can you guys spit out an XML schema?

I can not.  I don't understand XML Schema.  When I look at it my
brain gets fuzzy.  None of the tools I regularly use understand XML
schema, and my experience with schema-based (DTD) parser generators
is that they break, badly, when there is a normally forwards-compatible
change to the format.

>  Sorry to sound like a jerk but the RelaxNG website was last update in  
> Sept 2003!

Probably because it because ISO/IEC 19757 and is part of the ISO DSDL
effort.  More recent work is under the new name; NVDL perhaps?

   """ISO DSDL was developed in part as a reaction against the
      PSVI/Type-Annotation approach adopted by XML Schemas."""
            http://www.stylusstudio.com/xmldev/200605/post90040.html

>  I'll try and use Trang to spit out a schema but, again, this piece of  
> software is old and crusty.

Aren't there any Relax-NG data binders so you don't need the
conversion step?

Since you want JAXB, have you tried its (experimental) Relax-NG support?
   http://java.sun.com/webservices/docs/1.5/jaxb/relaxng.html
   http://java.sun.com/developer/EJTechTips/2005/tt0524.html

http://www.oxygenxml.com/ says it can convert between grammars,
    
http://www.oxygenxml.com/ 
xml_schema_editor.html#converting_between_grammars
> The converter allows one to convert a DTD or Relax NG (full or compact  
> syntax) grammar or a set of XML files to an equivalent XML Schema, DTD  
> or Relax NG (full or compact syntax) grammar. Where perfect  
> equivalence is not possible due to limitations of the target language  
> <oXygen/> will generate an approximation of the source grammar. The  
> conversion functionality is available from Tools -> Trang Converter .

As you can see, it's using Trang, which you've said is crufty.   
(Personally
I would love it if 5 year old software of mine was still going strong  
and
didn't need any more TLC from me.)

There are also the following, but they also seem too dusty for you.

https://relax-ng.dev.java.net/ (linked from Wikipedia) lists the  
following

   isorelax-jaxp-bridge  	ISO RELAX JARV API to JAXP 1.3 validation API  
bridge
   relaxer 	XML Schema Compiler
   relaxerstudio 	Model editor for Relaxer
   relaxngcc 	Application-level XML parser generator / data-binding tool
   rngom 	RELAX NG Object Model / Parser



>  Not sure what I'm going to get out of it. Why do I keep asking for  
> this? Because I'm LAZY.

And so am I.  Why would I want to do this?

> I want to use XML parsing libraries that bind XML Schema to Java  
> objects and vice versa. I can also look at a schema and code a SAX  
> document handler pretty quickly. Even a DTD would work here because  
> it's super easy to convert DTD -> XML Schema. Again, can I entice with  
> Beer/Wine? ;-)

The DAS2 schema is not hard.  Really.  Honestly.  We're using a  
full-blow,
ISO standards based schema definition, and a subset of that so parsers  
need
only single token lookahead for disambiguation.  It should be as  
trivially
easy to support RNG as to support a DTD, with the added bonus that DTDs
and namespaces don't mix.

					Andrew
					dalke at dalkescientific.com