[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Call for unifying and clarifying XML 1.0, DOM, XPATH, and XML Infos
> [Lars Marius Garshol:] > | [ Norman Gray] > | When I read the auxiliary XML specs (DOM, InfoSet, XLink,...), my > | first thought was `why are they creating a complicated version of > | HyTime?'. > > You are not the only one to react that way, although a case could be > made for the DOM being slightly more than just a new version of > HyTime. The DOM is an API. It describes functionality. That's good. The DOM API implicitly operates on something that certainly seems like a grove to me. That's OK, and, in fact, it's just great when InfoSet describes just what that grove-like something actually is. HyTime does not describe any APIs, so of course the DOM cannot be a reinvention of HyTime. > | (b) Separately from that, I felt that the standard was rather > | confusingly written; I strongly suspect, however, that this was > | because of the constraints of writing according to the ISO format. Too right. > | My impression was that there were at least _four_ standards here, > | which were linked but independent. Having all four in the one > | document produces an indigestibly rich pudding. Perhaps *much* too right. Personally, I would estimate a higher number than four. However, the set of standards that is ISO/IEC 10744:1997 (HyTime) interdepend in complex and important ways. I don't think the overall elegance of HyTime could have been achieved by segregating things like groves from things like architectural forms, as separate standards development activities. HyTime's most significant contribution is not any one of its separate component standards, but the sensible, economical, simple and powerful way they all fit together, having contributed vital requirements to each other. The W3C process appears to be based on the naive belief that independent design assignments for all the various aspects of Web-based information interchange can be made to a plethora of independent technical committees, and, in the end, everything can be made to work together somehow. Even when we combine all of the W3C's favorite magic bullets (RDF, XML Namespaces, XML Schemas, etc.), there's still no paradigm for the re-use of vocabulary-specific engine software, and no doctrine providing for the validation of the use of mixed vocabularies. Thanks to the dazzlingly brilliant insights of James Clark, who invented groves and who very significantly improved architectural forms, HyTime 1997 (aka HyTime 2nd Edition) got the basics of that stuff right -- very, very right. The fact that these insights have been systematically ignored by the leadership of the W3C is tragic. If I were working on W3C projects, I'd be very angry about the way that my time is being blithely flushed down the toilet by leaders who are trusted by everyone to know the state of the art, but who don't really, and who portray themselves as trustworthily knowing where W3C's technical developments are leading the world, when in fact they do not. As a public demonstration of what the leadership of the W3C does not know, I hereby invite the press to question the W3C leadership about how the W3C's standards-making efforts are addressing the blindingly obvious global requirement for a standard doctrine as to how modularly re-usable vocabulary-specific software engines can be used in applications that process the documents that use those vocabularies. For example, * How will the XLink vocabulary be supportable by an Xlink engine, and the XHTML vocabulary be supported by an XHTML engine, with both engines usable in a variety of applications contexts, and with both engines able to be built and marketed by any software vendor, and used in any combination by any application developer? (I suspect the W3C leadership's answer will be, "That's for The Software Vendor to figure out.") * Even more fundamentally, how will a document's use of both vocabularies be validated? When information interchange fails, it's vital to be able to point the finger of blame at either (1) the software that created the invalid use of the vocabulary, or (2) the software that could not understand a perfectly valid use of the vocabulary. (The Web culture's notion that "If 80% of the information gets through, that's good enough", simply won't fly in business-to-business communications. 100% is absolutely required. I claim that there is no such thing as a useful B2B vocabulary in the absence of a vendor-neutral, application-neutral way to determine whether that vocabulary is being used properly in any given instance. XML Schema *does not* address the problem of validating mixed vocabularies. As far as I can tell, this fundamental problem doesn't even appear on that committee's radar.) (The answer, "That's for The Software Vendor to figure out," is obviously not a good answer. Software vendors are not going to come up with a scheme whereby their product offerings can compete solely on their intrinsic value! That job can only be for their designated consortium, the W3C, to do.) * How will a software application that reads such a document invoke the two re-usable engines, incorporating their intelligence into itself? (If the W3C does not provide an answer to this question, then there can be only one source for re-usable vocabulary-specific software engines, in which case the term "re-usable" is kind of a joke. Long Live The Monopoly! Let the Monopoly Own All The Business Vocabularies of the World!) So far, the answers to these questions are undefined in W3C land, and yet the answers are essential for information interchange in a world that most of us hope will not always be entirely dominated by a single software monopoly. The answers to the above questions are fundamental to the development of any business vocabulary, and several fundamental business vocabularies are being developed by the W3C. How will these business vocabularies actually work together, huh? Dear Ladies and Gentlemen of the Press: Please demand the answers to the above questions, and please publicize the answers you receive. (Please also be aware of how HyTime answers them, and of how HyTime's answers are already working. I'll be happy to help you with this, and so will quite a number of other knowledgeable people.) > | What appears to be happening now is that HyTime is being reinvented > | piecemeal -- in the auxiliary specs -- which is bad for just the > | reasons Nils mentioned: specs seem to contradict each other, act on > | different information sets, require a forest of new terminology and > | concepts which may or may not be isomorphic to each other. > > I agree to some extent, and I think one way to handle this would be to > do a scaled-down version of property sets for the XML specifications > and then build things on that. This means that most of the difficult > stuff would have to go (grove plans, for example) and the terminology > might have to be simplified, but the simple essence could be kept. We should all welcome such an outcome! -Steve -- Steven R. Newcomb, President, TechnoTeacher, Inc. srn@t... http://www.techno.com ftp.techno.com voice: +1 972 517 7954 fax +1 972 517 4571 Suite 211 7101 Chase Oaks Boulevard Plano, Texas 75025 USA xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ or CD-ROM/ISBN 981-02-3594-1 Unsubscribe by posting to majordom@i... the message unsubscribe xml-dev (or) unsubscribe xml-dev your-subscribed-email@your-subscribed-address Please note: New list subscriptions now closed in preparation for transfer to OASIS.
|
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
|