[
Lists Home |
Date Index |
Thread Index
]
On 6/10/05, Henry S. Thompson <ht@inf.ed.ac.uk> wrote:
> That's me (although _my_ moor was very conservative, not wasteful at
all :-)
Sorry to hear about the squirrels. I thought Robin was making that up:-)
> Four years since the launch of W3C XML Schema, I guess I think the
> parallels are pretty clear -- you have to invest a certain amount of
> real effort to get comfortable enough with the architecture of the
> spec so you can reliably put your hands on the right part of it
> for a given task; interop is much better than it was (although
> certainly not perfect, but for a four-year-old not bad); good SDKs are
> _just_ beginning to emerge. So, for me (not surprisingly), definitely
> half-full and still filling, not half-empty.
I'm sure my 2001 self is horrified, but I pretty much agree. XSD
would have been a lot better if the WG members had tried harder to
understand what MURATA Makoto was saying about what eventually became
RELAX, or if W3C had in place the more rigorous interoperability
testing procedures they have now, or if they had just paved the
well-travelled footpaths rather than surveying new ones. But we'd all
be a lot richer and more successful if we had known in 2001 what we
know today.
Derek reflects on our group's not very happy experience
http://nothing-more.blogspot.com/2005/06/xsd-aka-w3c-xml-schema.html
implementing XSD and what it means going forward. "XSD is mostly
acceptable to a much wider variety of real use-cases, more so than any
of the competitors." I remember Dare publicly agonizing of the
dilemma that thaere are plenty of things that RELAX NG is better for
than XSD is, Schematron has a lot of power that could complement
either of them, but it's awfully hard to make a case for supporting
them in MSXML or .NET at this point. Nobody except ubergeeks ask for
them, and anyone advocating them internally gets asked a lot of hard
questions about what happens if (hypothetically) people develop
applications with the core tools with RELAX NG and expect them to work
with Office, BizTalk, SQL Server, etc, not to mention interoperating
with the tools of other vendors who have invested in XSD.
Looking forward, there seem to be two basic options: Buckle down and
make XSD work and interoperate better for mainstream XML use cases
(requring clarifications to the spec, probably some more errors fixed,
a much more complete test suite, and a LOT of debugging) ,,, or
pretty much start over, revisiting all the arguments about use cases
and type systems and surface syntax space vs underlying value space
and all sorts of other things for which there are simply no good
answers. I have no faith that a consensus-driven process will get it a
lot better next time, so I think we're stuck with just making XSD
work.
It's easy to say that XML experts shouldn't have a problem giving up
the object and database mapping use cases that XSD tries to handle,
but that's a hard sell to business application programmers who want to
just focus on their business logic rather than infrastructure voodoo.
It's easy to make the case that RELAX NG is simply better than XSD for
pure text documents, but real business documents have an awful lot of
typed data and close couplings to business processes and service
interfaces that XSD handles reasonably well. Believe it or not,
thousands and thousands of people have made XSD work fairly well for
their documents that are created with the Office 2003 products,
whatever the revealed wisdom here is about how hard that is. This is
not the world I foresaw in 2001, but it's the one that has come to
pass, and I think we just need to deal with that reality.
We also have to deal with the reality that has come out in this
thread, especially that there are a lot of use cases for co-occurrence
constraints in document-oriented applications that XSD can't handle.
I'm not sure what we (MS and/or the XML community) should do about
this. Schematron in particular sounds promising as a way of
supporting these use cases in a way that complements XSD without
horribly confusing users, but we need a lot of experimentation and
success stories to see how this can be done cleanly.
So, the best way forward IMHO is to keep filling the XSD glass, and
maybe doing some long-range R&D to figure out how to do it
dramatically better in XML 2 or Son of XML, or whatever it is that
will eventually transcend the XML 1 generation of technologies.
|
