Re: ATTN: Please comment on XHTML (before it's too late)
W. Eliot Kimber writes: > > 1. It is necessary to perform three tests rather than one to identify > > a name from XHTML: that means three separate patterns in XSL (for > > example), three separate contexts in a context-sensitive search > > engine, three separate XML queries, three separate XPointers, > > etc. etc. > > I think that points up a general failure with the architecture: > what you really want to do is match things based on their base > semantic binding, not on their local name. Namespaces don't (and > can't) do that. If there was an explicit ns-to-semantic-definition > binding, it wouldn't be a problem, because you could establish > clear and machine-understandable type hierarchies and process in > terms of any point in the hierarchy. > > But that requires a lot of machinery, which is probably beyond the > W3C to define at this point in time. The definition is not the problem -- the implementation and deployment is. Any standard that requires the processing of a large schema to make sense of a small XML document will probably fail. XML Namespaces cannot work the same way as classes and interfaces in a closed system -- all of the useful information (or at least enough of it for processing) *has* to be in the document instance itself, not in a separate schema that might reference another schema that might reference another schema, etc. That means that a Namespace URI is a lot like a domain name -- a single, well-known public identity for a collection of markup definitions -- and not very much like a class. > It also points up a problem with simple-minded processors that make > assumptions about local names that are not justified. Simple wins, complex loses. I remember avidly reading the literature about the complex experimental hypertext systems of the late '80s and early '90s, but they lost and HTML won. Now, maybe HTML was a little too far on the stupid side, but not so far that it couldn't mop the floor with the competition. SAX 1.0 is widely implemented because it is simple: everyone has one or two more things they'd like to see in SAX, but since everyone's one or two more things are different, SAX would have become quite complex if it had tried to accomodate all of them, and probably no one would have implemented it. > A request like this, while probably reasonable on practical grounds > (which I don't dispute) cannot be justified on practical grounds > alone--there are clearly important architectural issues that this > problem is exposing that need to be resolved. Once those architectural > problems are resolved, then the appropriate practical solution should be > obvious (or at least easily developed). Architecture in a closed system (like a single company or supply-chain) can evolve top-down, just as a single company can reasonably hope formulate and follow a business plan. Architecture in an open system (like the Web) has to evolve bottom up, just as successful economies tend to develop despite government intervention rather than because of it. In other words, when you move to the macro level, all of the rules change. > > All of this means three times the opportunity for bugs and > > interoperability problems (and yet more accusations that the W3C > > cannot create specs that work together). > > I think it's a little too late for the last one. At least we can keep trying. > I'm sure that versioning is a big problem. And I'm sure that whether you > use one ns per version or three doesn't really matter: the nature and > severity of the problem are the same. Or rather: if you can manage one > ns/version you can manage three and if you can't manage three, you > probably can't manage one. Bingo. I believe that there should be just one XHTML Namespace as long as possible, just as a company should stick with the same domain name. All the best, David -- David Megginson david@m... http://www.megginson.com/ 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
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