Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: QNames in attribute values
 Ron Bourret wrote: > Evan Lenz wrote: > > > Consequently, all scope > > information, i.e. exactly where every xmlns declaration is and > > what prefix > > it uses, must always be passed to the application, regardless of whether > > it's needed or not. > > But that's hardly a lot of information, is it? It is for any specification or tool that's intended to support general XML. Take XQuery, for example. In-scope namespaces, whether as specified in XPath 1.0 or otherwise, represent a large storage and/or run-time burden in comparison to the extent to which they are actually needed (i.e. when QNames are used in attribute values). When copying an element, all of the in-scope namespaces must be determined and copied along with it. That either means replicating namespace nodes for each of every element's in-scope prefix-URI bindings (as XPath 1.0 does) or specifying an elaborate namespace fixup algorithm by which the in-scope declarations are identified and new declarations are appropriately added to the result. The semantics of XQuery element constructors becomes unwieldy. That [in-scope namespaces] is part of the Infoset isn't much consolation. Like Canonical XML, it's just taking its cues from other specifications. Perhaps what's needed is some serializable bit (PI?) that indicates whether [in-scope namespaces] are significant or not. Of course, the default would probably have to be the status quo, i.e. that they are. Then, XML database users would be advised to add <?xmlns preserve="no"?> to the beginning of all documents except XSLT stylesheets, XML Schemas, WSDL documents, etc. <snip/> > > If each layer had its own > > namespace declaration mechanism (one for element/attribute > names, and one > > for application-specific content), then it would always be > possible to throw > > away scope information as purely lexical detail. > > Yes, but the end result would be that many applications would end up > reinventing xmlns attributes. I think that application-level namespace declarations would look a lot different than xmlns declarations for a number of reasons: Most applications (that use QNames in content) will not need the generality of xmlns scoping. For example, in XSLT, users almost always attach all namespace declarations to the xsl:stylesheet element. An application-level declaration such as a top-level instruction listing prefixes and URIs should meet 99.9% of use cases. (You could still use xmlns wherever you want for literal result elements; this is only for QNames in XPath expressions.) Furthermore, it would make complete sense from the user's perspective to separate the two namespace declarations. One (xmlns) would be used for literal result elements, i.e. the result tree. The other (say, xsl:namespace-decl) would be used for referring to elements by name, i.e. the source tree. If you're translating from XHTML to XHTML, then, yes, you'll have to repeat similar declarations. Most often, however, transformations go from one vocabulary to another. When they do, in XSLT 1.0, users are forced to use the exclude-result-prefixes attribute to get rid of unwanted namespace declarations in the result. They appear there because of namespace declarations in the stylesheet whose only purpose was to resolve QNames in XPath expressions. The user has to explicitly clean up after this overloading of namespace declarations to do two very different things. <snip/> > How are they being "forced" on applications? DOM doesn't do this (which > I think is a mistake), and it's trivial to ignore this information in > SAX if your application doesn't need them. > > Put another way, I don't care about entity usage. Should I also complain > that entities are being forced on me? Good question. I think this is pretty different. For one thing, entity boundaries are not in the Infoset, whereas in-scope namespaces are. I can't think of any XML vocabulary that's interpreted differently based on whether entity boundaries in the instance are discarded, let alone break if they are not preserved. (Are there any?) But that's precisely what happens when in-scope namespaces are not preserved. Thus, general-purpose XML applications, such as XML databases, query languages, transformation languages, etc. *are* forced to deal with in-scope namespaces as part of the data model, but they are not forced to deal with entities as part of the data model, at least not by any W3C precedent that I've seen. (Note that being forced by necessity to support something is different than providing support as an added value.) Evan 
|
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
|
|||||||||
