[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: More on Namespaces
David Megginson wrote: > > Personally, I'd like to separate the issue of global names from that > of document composition: I do not think that namespaces are a useful > substitute for subdocuments (inline or out-of-line) -- that issue > still needs to be dealt with. Yes. But when I read the specs and look at the examples on some sites, the assumptions are easy to make. There are documents that use the words "namespace" and "schema" in the same sentence too often to assume otherwise. > In other words, an element named "http://www.megginson.com/ + para" in > one document and an element named "http://www.megginson.com/ + para" > in a second document have the same name. Make of it what you will. Ok. I understand that. Taken on its face, if the URL is unique, the element strings are identical. It is the URL that is the unique part. It only establishes a mechanism for making it unique. It doesn't carry the promise as a Doctype does that at the other end of this, say, system literal is a description which not only provides a unique local namespace, but also the frequency and occurence of that element in an instance. > > So what am I to assume if I see a dt: prefix that has a classID > > in the ns attribute, and another that *appears* to point at > > a schema of some sort? > > I'm not certain that I understand the question -- could you give an > example? Not from home. I have seen examples in which the namespace URL points to different things; specs, schemas, and classIDs. That confused me but given the above, I think I understand what you are getting at. The schema may be there but that is not the namespace mechanism. > The WD contains much in the line of confusing and mostly-irrelevant > philosophical musings that (I hope) will eventually be deleted -- if > Len finds the spec confusing, I'm terrified of what will happen when > it hits the webmasters. Well, Len is spending his free days reading everything on the public W3C site to work through all the specs. I don't think one can fairly work out the system without understanding all of the components. Some of this relates to work, some curiosity and the markupJones, and some because of the issues with VRML and the kudzuProperty of markup systems. Anyway, as I wake up from some years of insulin deprivation, maybe my grokking will improve, so I am not a fair comparison right now and certainly have to catch up. > With the latest namespaces WD, however, XML can no longer fairly claim > to be simpler or more transparent than SGML -- the contextual > dependencies built into local scoping and defaulting are in the same > class as the contextual dependencies built into SHORTREF and OMITTAG > (both of which XML wisely discarded), though the algorithms for > resolving the namespaces are considerably simpler. I trust you are right. I never had to write code to do those and I never used those features. Yet, perhaps it is time to acknowledge that this project is not simply SGML On The Web: given the DOM, et al, it is the project to overhaul the WWW products and provide a stronger and extensible, and more importantly, standardizable system. Flying in the faces of the vendors doesn't work. We need requirements, specs, and conformance tests. IOW, make it clear enough and cheap enough to do the right thing so that doing the wrong thing simply makes no economic sense. The best way to get them follow the standards is to make it expensive to do otherwise. > It is up to the reader to decide whether the fact of this complexity > vindicates HyTime or indicts XML. XML won't be indicted. We will suffer for the early hype as HyTime did. OTOH, we have to be clear along the lines of the statements I used to make to the IETM community: when you say interactive, you say code. HTML spawned a community that believed it could do multimedia without code. While that group may mainly only consist of marketing wonks now, we have to deal with the issue that XML 1.0 is just the syntax piece of a much broader system that taken altogether is more complicated than SGML because it attempts to do more than SGML attempts. HyTime may be vindicated by something most of us already knew and XML+TheRest makes clear: open hypermedia based on open standards is a very hard problem. Since every document I've read on the W3C sites clearly acknowledges parentage, there is no call for official vindication. We just have to acknowledge the problem is hard, we learned a lot from the previous attempts, and now we are iterating through yet another design, older, wiser, and ready to get it done. > The temptation to obfuscate is hard > to resist. Ha! We are victims of our erudition. len 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/ 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
|