[
Lists Home |
Date Index |
Thread Index
]
On Sat, 10 May 2003 10:46:27 +0100, Simon St.Laurent
<simonstl@simonstl.com> wrote:
> It is very difficult for me to get excited about more recent
> specifications, despite having spent/wasted an enormous amount of time
> sorting out W3C XML Schema for myself. I've put in the time and I've
> concluded that W3C XML Schema is poison from top to bottom, structures to
> datatypes, a misbegotten attempt to treat XML as if it were objects
> and/or relational database content with a tip of the hat to XML 1.0's
> basic set of attribute types and a 'mixed' feature.
Well, I wouldn't go that far, and I have little nostalgia for the good ol'
days of SGML and early XML, but Simon touches on some fundamental reasons
that address Dare's issues [cranky flamebait snipped :-)]:
"The fundamental complaint I have about XML-DEV is that people are very
good at generating megabytes of mail traffic about technologies they
neither have used nor tried to understand.... I've read the complaints
about ... dependencies on W3C XML Schema have failed to see any valid
issues
brought up. ..This is unfortunate since I was hoping I'd see more
criticisms of the
family of specs from a technical perspective"
My take:
- The resistance to XSDL and types in XQuery, etc. (besides Simon :-) of
course ) isn't so much about the idea of strong typing (as opposed to
static typing, and yes the terms get quite mixed up in these discussions)
but the specific type system in XSDL. Those 40-odd builtin types (and just
shoot me if I'm confused about the terminology here too!) just invoke the
gag reflex, sorry.
- Lots of people simply don't have time to track these huge specs, so they
wait until last call because it's confusing to keep looking at a moving
target. OK, no more excuses, it's time to plow through this stuff! ... but
it's pointless to complain about people who haven't wanted the headaches
previously. Without stable specs and interoperable implementations, this
stuff simply doesn't get the attention of people who are out there actually
building applications with XML.
- "misbegotten" and "poison" may be a bit strong, but the fact remains that
both XSDL and XQuery have been largely driven by the needs of the RDBMS
vendors and vendors of development tools for statically typed languages. I
can only assume that all the gHorribleKludge stuff can be rationalized by a
need to map between the type systems of various flavors of SQL and various
programming languages. It's certainly not a concept that is at all native
to XML. The "XML view of an RDBMS" or "XML serialization of an object" use
cases are definitely valid ones, but not ones that excites a lot of people
here who are using XML views of, uhh, XML.
- Some of the confusion and *possibly* unfair assertions that XQuery is
inextricably bound up with the philosophy of static typing (e.g.
http://seanmcgrath.blogspot.com/2003_05_04_seanmcgrath_archive.html#200265755
where Sean links to the XQuery magnum opus in the sentence "Sadly, those
who really, really like static typing have also penetrated the XML world to
terrible effect in recent times") come largely from the advocacy about the
benefits of static typing by XQuery WG members on this list and elsewhere.
So, I think that much of what is *better* about this latest draft of XQuery
et al. than the early drafts is in fact due to the "megabytes of mail
traffic" on this list, the xsl list, etc. pushing back on the more
questionable decisions about to tightly bind these specs to XSDL and/or
the PSVI. They may not seem like valid concerns to someone working on XML
views of objects or databases, but they reflect the valid concerns of real
people. In other words, LOTS of valid issues have been brought up (and
addressed in a thoughtful manner by the various WGs). I suspect that there
are a lot more and once again urge people to review these drafts with an
open mind, but let's KEEP pushing to make them truly fit the needs of the
XML community. We've seen what happens when collective exhaustion leads to
a spec being made a Recommendation before it was really ready for
interoperable implementation and full of conceptual oddities that reflect
committee compromise rather than conceptual clarity.
|
