[DAS2] We need your input for DAS/2 spec freeze!
dalke at dalkescientific.com
Wed Nov 8 00:59:04 UTC 2006
> 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
case, plus the use of any other valid namespace prefix as an
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
Those are the HTTP error codes. See the HTTP spec for them.
Experience with DAS1 strongly suggests that another layer of response
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
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."""
> 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
Since you want JAXB, have you tried its (experimental) Relax-NG support?
http://www.oxygenxml.com/ says it can convert 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.
I would love it if 5 year old software of mine was still going strong
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
isorelax-jaxp-bridge ISO RELAX JARV API to JAXP 1.3 validation API
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
ISO standards based schema definition, and a subset of that so parsers
only single token lookahead for disambiguation. It should be as
easy to support RNG as to support a DTD, with the added bonus that DTDs
and namespaces don't mix.
dalke at dalkescientific.com
More information about the DAS2