James Clark wrote: >>Charles Reitzel wrote: >> Namespaces are an inherently global construct and I can see no >> reason why document writers cannot live with a single prefix >> per global identifier within a document. > > See http://www.w3.org/TR/NOTE-webarch-extlang#Local for > some reasons. Thanks for the pointer. It is just what I had been looking for. I read the section you referenced, and have given the reasons a good deal of thought, but I cannot agree with the premises put forward. Knowing in advance what namespaces will be combined in a document does not prevent tractable (I submit, better) solutions to each of the three problems mentioned. Before addressing each case, I think I have found an underlying difference in how folks view the namespace prefix. One camp sees the prefix being defined *by* the DTD and therefore as a global identifier itself. The other camp wants to define the prefix *for* a DTD and, thus, only within a document. Specifically, if the namespace is set as a #FIXED attribute for an element in the DTD, then prefix collision is likely (unless the entire global ID is used as a prefix). This is an inherent shortcoming of the prefix notation and inhibits DTD reuse. IMHO, a more useful approach for most developers is as I posted (based on others' previous posts): prior to "including" each DTD, set the default namespace. The objective is to associate a DTD with that namespace without changing the DTD. Perhaps a new syntax is needed to make this association explicit. An analogy might be using VMS logical names or Unix environment variables (e.g. $DATAHOME=//Host/Dir/Sub") to point to a resource that can move or change. David Megginson wrote: >Some people imagine that parts of large XML documents will be >constructed by many subprocesses spawned by a master process. These >subprocesses may need to declare and use their own namespaces -- the >thinking is that it would be unacceptable to require them to >communicate with the master process to negotiate a >namespace-declaration and prefix, so they must be able to declare >namespaces that are applicable only to the fragments under their >control. Thanks for the explanation. I have trouble understanding this concept. It sounds a bit like adding a chapter to the book but leaving it out of the table of contents. The three cases laid out in the "Extensible Documents" note referenced above are: a) legacy documents (the CGI example) b) Long documents c) Document concatenation The short answer to each of these "requirements" is for the author of the composite document type to create wrapper elements. This is analogous to the programming practice of hiding 3rd party library calls within a thin, locally defined layer of function calls. Thus, allowing the application to (more easily) substitute the external resource should the need arise. a) legacy documents (the CGI example) One should be able to declare, in the DTD, the element types used by such sub-document and associate each with its global namespace id and a locally unique prefix. Where validation is not used, simply wrap the legacy elements within a wrapper element that uses a declared namespace prefix. All child-elements then default to that namespace - no fuss, no muss. b) Long documents If a document is truly huge, a few namespace declarations at the top are the least of your worries. Certainly, the example of a new namespace for each paragraph is degenerate and should not be the basis for design. As for "working set" size (i.e. per process memory), I submit that normalizing the namespace declarations (i.e. once each at the top of the document) can make the space cost of namespaces much less. Each element that belongs to a different namespace than its parent need only concatenate the local prefix to its name and not re-declare the global identifier. Say a large document has ~100K elements. Wouldn't it be a misuse of namespaces if the number of unique global namespace id's was more than ~1K? Thus, we have just eliminated the text of the 99% redundant global identifiers. If one is seriously constrained, break up the document and link the separately parsed parts (as David M. and others have suggested). Again, the extreme case should not be used as a basis for design. Optimize the typical case; allow the odd case. c) Document concatenation Why is it inherently desireable to concatenate arbitrary XML documents? Certainly real applications will construct complete documents from prepared fragments (after all, this is one of the primary motivations for namespaces). But any arbitrary documents? Is this a pressing concern to any prospective XML implementers? If you must concatentate, simply create a wrapper element. === I may be all wet on this stuff. Really, the only way to make good decisions about these things is to use real-world examples. Has anyone compiled a set of "use cases" to validate prospective xml designs? The two main ones I keep hearing about are complex content publishing (one document, many output media) and ECommerce/EDI. What are some others? Charlie P.S. The XSL WD looks excellent. I need to study it more before I can appreciate the details (pattern matching!). The basic transform/render architecture is real clean and will make XSL useful for many non-visual applications (generate UN/EDITFACT from XML/EDIFACT!). The requirements doc was very helpful. Anyway, I look forward to using XSL. 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