[
Lists Home |
Date Index |
Thread Index
]
On Mon, 2002-06-10 at 22:59, Jason Diamond wrote:
> > How does typing something as Notation, as NCName, as gMicrosecondEon, or
> > as unsignedLong help me to unpack an XML instance into Java native
> > storage without knowledge of semantics?
>
> You're focusing on the wrong kind of types. SOAP toolkits can usually
Umm, no. I'm pointing out that those things are also required to be
supported, by XSDL. Bloat as well as incompleteness.
> generate language-specific bindings that make it really easy to read and
> write XML. Element declarations bound to complex types become classes.
> Locally scoped elements (and attributes) bound to simple types become the
> member variables of those classes. The form in which those language-specific
> bindings take isn't important and they'll obviously be different for each
> language. What's important is that the mapping is automatic and that valid
> instances of the types can be parsed and emitted without requiring precious
> development time being spent on such low-level details.
In my experience so far, it doesn't work, except for demonstration code.
Demonstration code abuses XSDL as expected; it uses register-based types
defined in correspondence with the register-based XSDL types. Domain
objects rarely contain integers with a range of -32768 to 32767.
Automatically mapping to a signed short may be convenient if you've
defined your schema based on what the developers have available, but is
somewhat less than ideal if you've defined the schema based on the
reality of the domain.
> A Java-specific binding for an unsignedLong derivative could use BigInteger.
It could, but it doesn't have to. It might instead use long, and handle
the value transposition itself. Since there is *not* a direct mapping,
opinions can and do differ over what the correct mapping ought to be,
and tend to be application-determined.
> The setter for that field could enforce whatever restrictions were placed on
> the simple type in the schema. What's really important to the developer
> using this toolkit is that the conversion from XML to the native constructs
> supported by his language and back again happen automatically. He didn't
> have to type in a single pointy bracket. SAX and the DOM or whatever the
> generated code used to parse the XML is completely hidden from him as well.
For any custom conversions, this may not be the case. A great deal
depends, again, on whether the developers get to design the schema,
based on the capabilities of the target language's type system, or the
designers create the schema based on the problem domain's requirements.
If the domain requires an integer in the range 1 to 50,000, what's the
proper type?
unsigned short? That works, but not in Java. Also, the actual value
carried around needs the extra information that it's a constrained
short, which cannot have the value 0 or values greater than 50,000. In
Java, signed int, with constraints? But it's perfectly possible to
define it as a range of -20,001 - 30,000, plus an offset of 20,000.
> XSDL is hardly the best language for just validation. DTDs are fine for
> that. RELAX NG is even better. Use the right tool for the right job.
Horsefeathers. Structural validation is only half of the issue. The
point of describing typing as a specification of validation algorithms
is that that's how you do it purely within XML. Anything else requires
knowledge of the target language. Validation requires only knowledge of
what the constraints are, for simple types, semi-structured types, and
structured types. Restricting validation solely to the domain of
structured types certainly does imply that one doesn't need XSDL, or
typing of simple types at all.
Amy!
--
Amelia A. Lewis amyzing@talsever.com alicorn@mindspring.com
It's is not, it isn't ain't, and it's it's, not its, if you mean it is.
If you don't, it's its. Then too, it's hers. It isn't her's. It isn't
our's either. It's ours, and likewise yours and theirs.
--OUP Edpress News
This is a digitally signed message part
|
