Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Imminent death of Namespaces predicted (was: Namespaces are dead.)
 From: David Megginson <david@m...> >Rick Jelliffe writes: > > > If I have to change namespaces URIs to generate acceptable data for > > different uses, then namespaces are not providing universal names > > as they should. > One can hardly >claim in any fairness that this is a breakdown in Namespaces -- it's a >business problem that (with any scheme) can be solved only by the >long, laborious process of discussion, trial implementation, and >standardization. What has it has it got to do with business or discussions? Any application family (stylesheets, schemas, etc) which does not have a mechanism (like the stylesheet PI) to allow plurality of alternate technologies (like CSS, XSL, DSSSL) ties its names into a specific technology. W3C needs to make it standard procedure to define PIs (in whatever syntax) to allow this plurality. Everytime there is a major application family with no accompanying mechanism, it subverts the intent and use of namespaces. Instead of providing universal names, it provides application-specific names. Do you see the difference? It is a matter of providing a level playing-field. Of course we can reprocess a document at the server end and rename the namespace URIs for every different application; of course we can use content negotiation to use the namespace URI as a key to the specific application we are using; of course we can have a PI at the client that rewrites part of the DOM so that other applications can get to use the data. But it is an unnecessary complication: if we want open and extensible documents, they shouldn't gratuitously make it difficult to retarget the document for different applications. Of course when we use a different stylesheet language we may have to restructure the document for best use: but we should only have to do that to reflect the nature of the specific stylesheet language, not merely because we are allowing an *alternative* language. It is inefficent and promotes data capture, which is one of the reasons everyone wants to escape proprietary syntaxes. Data capture is when a data format gratuitously ties in data to a particular (vendor's or consortium's) technology: "embrace and extend" or "embrace and lock-out" are the same. We users demand that application-specific markup be cleanly partitioned in a documents; we want namespaces to be equally accessible for every use. > Exactly the same problem could occur with >Architectural Forms or any other mechanism for naming or subtyping. Without going into details about how much namespaces share with architectural forms...yes: it is a basic fragility of namespaces as currenly specified. It should not be solved ad hoc by discussion, but a standard procedure to enable extensibility and plurality. Namespaces are dead, not because they are wrong IMHO, but because they can be killed and are being killed, and we can safely predict that without a mechanism to prevent data capture in every public application area, they will be killed again in the future. The reason why I excluded literature in my initial post is that, with the Schema PIs, namespaces have escaped death for rendering applications. Rick Jelliffe 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
|
|||||||||
