Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Document oriented experience reports anyone?
 On 6/10/05, Henry S. Thompson <ht@i...> 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. 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
