Reading that Dennis, I actually think we're in the same camp. :) Thanks
for taking the time to re-illustrate your position (I missed it in earlier
threads).
I have NEVER understood why XML Schema went as far as it did - extending
simpleTypes to restrict values based on regular expressions seems to me to
be out of the scope of a type system.
Given that not many Schema -> OO type mapping tools currently even support
XML Schema to that level, we typically stick with plain-jane complexType,
element, and attribute declarations. So far it's proven a safe strategy for
WSDL2xxxx toolkit iterops.
Maybe we'll see an XML Schema "Lite" in the future?
-Jon
-----Original Message-----
From: Dennis Sosnoski [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 16, 2004 5:29 PM
To: [EMAIL PROTECTED]
Subject: Re: Doc/Literal support in axis
Anderson Jonathan wrote:
>...
>The $5000 Question:
>Should we not have native support in a programming language for XML Schema?
>Why all this mapping nonsense?
>
That appears to be the "bold new computing direction" of the month for
Microsoft. I think it's a bad idea.
<flame>Schema is a design-by-committee monstrosity that makes the old
Ada programming language look clean by comparison, combining the worst
features of SQL and VB. Why would anyone want to bake it into a
programming language?</flame>
>
>To quote another colleague of mine: "the W3C really created a monster with
>XML Schema. It's far more powerful and expressive than most OO type
systems
>like C# or Java."
>
Schema does a decent job of letting you define XML structures. It also
has a fairly nasty hodgepodge of types that, while awkward, at least
allow you to express the intent of what you want to see in different
components of your XML. Then it adds a truly bizzare set of ways to get
down to the detailed level of what each component should be - things
like the multitude of facets, regular expression matching, extensions of
restrictions and restrictions of extensions, etc. What makes the latter
set of detailed data descriptions of little use in practice is that
there's no way to condition the values permitted for one attribute or
element on the values (or even presence or absence) of another attribute
or element.
Sure, you can do really complex descriptions of simple text values in
schema - there's a 100-page ISBN number schema I use as a look-at-that
example in training classes, for instance - but why would you want to?
For real applications schema validation is going to be prohibitively
expensive once you get into the complex rules, and most applications
require more intelligent data validation than schema can support anyway.
My recommendation for anyone writing schemas is to use it for structure
and basic data types, but stay away from the facets and such unless you
really have a need to use them for descriptive purposes... and then
don't write your program on the assumption that the facets will be
enforced, for two reasons: (1) if someone changes the schema your code
will break, and (2) schema validation will probably be turned off when
you're deployed.
- Dennis
Dennis M. Sosnoski
Enterprise Java, XML, and Web Services
Training and Development Support
http://www.sosnoski.com
Redmond, WA 425.885.7197
