Re: why do namespaces have such a bad rep 
[James Anderson <james.anderson@m...>:] > first, an aside for those who may wonder why i pursue this. my > concern is that i do not wish to have to implement support for > enabling architectures just in order to contend with name > collisions. on principle it would be wrong. practically it would be > a waste of time. (1) You don't have to implement it. It's already implemented. It's already free, in source form, too, without restrictions of any kind, except that you can't use James Clark's name in certain ways. (2) If you're determined to argue this point on the narrowest possible grounds (even though those are not the grounds I'm arguing on), how's this? "Enabling architectures, among many other things, is a way of handling name collisions. If the sole purpose of namespaces is to avoid name collisions, and if you don't have to implement enabling architectures, then on principle it's a waste of time to implement namespaces. Q.E.D." (3) Enabling architectures would enable RDF to meet real requirements and desiderata that RDF can't satisfy today because it doesn't have enabling architectures. The simplifying assumption that namespaces represent ignores and renders useless the most powerful aspects of the schemas that represent architectures (i.e., DTDs). Among other things, RDF is supposed to support electronic commerce. Electronic commerce is a limitlessly hard problem in data interchange and management. It's not a good idea to discard or cripple the tools we already have for dealing with hard problems in data interchange and management. The namespace solution and the enabling architectures solution are *not* orthogonal to each other, unless you restrict your vision to extremely narrow and purely implementational concerns. If you're sensitive to the economics of mindshare, or to the very real cost of having two things, one less powerful than the other, where the one more powerful thing alone will do the job, you will see the connection. Let me put it even more starkly. It makes no sense, in a small living room (the short supply of mindshare and attention), to replace a comfortable sofa (enabling architectures) with a rude wooden bench (namespaces). It doesn't matter how many times you say that the wooden bench is perfectly good for the purpose for which it was designed, and it doesn't matter how many times you point to the bench's original specifications when people complain that, in practice, the bench is sometimes very uncomfortable and a sofa would be much more useful in a wider range of everyday living situations. > i use namespaces. i have implemented namespaces. I suspect yours is a very fine implementation, too, and, believe me, I sympathize with your situation. My company has done several implementations of nascent standards, only to throw them away and start over when it became clear that any tendency on our part to cling to our investment would stand in the way of progress in the larger context. Our HyQ implementation is an example. Perhaps you remember HyQ, the HyTime query/addressing language that was replaced by SDQL -- a replacement that I firmly and immediately supported, despite the emotional stress of abandoning a pile of work and a substantial investment. (Don't get me wrong; I've never regretted it.) > you're right there. one thing i still need to understand is how i would, for > example, define things like the ArcCFC entities for multiple inherited > architectures (ISO/IEC 10744 p230), or handle possible name ambiguity between > multiple architecures wrt entities used to specify section inclusion (ISO/IEC > 10744 p223) > (yes, i lack experience there. i woud presume one helps oneself to dotted names, > but that's just conjecture) The parameter entity namespace collision problem can occur only when you're syntactically inserting a DTD into the architecture you're creating. The potential for parameter entity name collisions, in such a scenario, is a feature of (or, one could conceivably believe, a bug in) SGML's DTD syntax. Fortunately, such inclusion is never necessary in order to obtain the full benefit of enabling architectures; you can always just map everything you need in the usual fashion, by declaring element types in your inheriting DTD that conform to architectural forms (the element types in the inherited-from DTD), and thus refer to, rather than include wholesale, the enabling architecture's DTD. If your enabling architecture has ArcCFC parameter entities, simply expand them in the normal SGML way, see what effect they have on the enabling architecture's effective DTD, and use the result as your enabling architecture. You always have the option of allowing whatever was declared as context-free in the enabling architecture to be used with equal lack of constraint in your inheriting architecture. Or, you can constrain the context-free elements to appear only in certain contexts; it's up to you. Whether you choose to declare context-free elements by means of a parameter entity whose name happens to be %ArcCFC; is entirely your business. (All parameter entity names in your inheriting architecture are entirely your business. In fact, even when inheriting any number of enabling architectures, means are provided to allow you to prevent them from affecting any of the inheriting architecture's namespaces in any way.) The marked section modularization technique used in the 1997 HyTime architecture has nothing to do with the concept of enabling architectures. The marked section stuff in the HyTime architecture is just a technique that helped us get the HyTime standard published in a way that allowed the whole HyTime architecture to be self-documentingly and self-realizingly modular. It is a pretty cute, if somewhat Byzantine technique, but it seems obvious, in retrospect, that the modularity of the HyTime architecture would have been better and more neatly achieved by making each of its modules a distinct enabling architecture. Unfortunately, that realization didn't dawn on us in time to meet the 1997 edition's publication deadline. *Sigh* Live and learn. Sorry for any confusion it causes. (The concept of enabling architectures has nothing to do with the HyTime architecture, either, except that, (1) when used as such, the HyTime architecture is just an example of an enabling architecture, and (2) both the HyTime architecture and the enabling architectures paradigm are standardized in single ISO book under a single ISO standard number, viz., 10744:1997.) Anyway, please understand that I'm not trying to defend particular syntaxes. By speaking out against XML namespaces, I'm attempting to conserve the public's mindspace for underlying concepts and intellectual tools. With the minimum set of the most protean possible concepts and intellectual tools, we may hope to grope our way toward more intuitive and more convenient schema syntaxes. On the other hand, with a wildly overlapping set of specialized, narrow-gauge tools (XML namespaces leap to mind as an example), I doubt we can ever get to a place where we have a really good, fully generalized schema syntax. In that case, I think we'd better stick to SGML's DTD syntax, warts and all, because it is known to work and, as an existing international and W3C standard, we won't have to fight over it. We can just keep on kludging it up with things like colon-ized namespaces and architectural form attributes. To all those who have read this whole harangue: you have my thanks and sympathy. -Steve -- Steven R. Newcomb, President, TechnoTeacher, Inc. srn@t... http://www.techno.com ftp.techno.com voice: +1 972 231 4098 (at ISOGEN: +1 214 953 0004 x137) fax +1 972 994 0087 (at ISOGEN: +1 214 953 3152) 3615 Tanner Lane Richardson, Texas 75082-2618 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/ 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