Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Namespaces design implementation?
 Tyler Baker wrote: > > I am sure this question has come up in private circles, but on this > particular list the question of whether to integrate the current > namespaces draft into the core of an XML parser/XML framework or else > put it all in a layer on top of the parser/framework has not come up to > date. The topic has come up. So far as I've been able to tell, the "resounding" preference has been for layering it on top of the parser. The opinion has not been universal, but I believe, I am correct in reporting that a very limited number of correspondents have spoken up for alternatives. :) > The reason I ask this is that right now I have to make a major design > decision about how to integrate namespaces support into the > parser/formatter I have been working on. I have about 5 different > implementation designs that I have worked up, each with their own > memory, speed, and API ease of use tradeoffs, so figuring out the answer > to this question is quite important. XML can do a lot of great things > without namespaces, so keeping namespaces as a separate and distinct > layer gets my personal vote. Nevertheless, I am a peon in the whole > scheme of things who has no real input into this particular issue so any > help in obtaining an answer to the previously stated questions would be > greatly appreciated. You do not describe your alternatives, but I would suggest that the real issue is not whether namespace support is in a separate layer, but whether the application operates on names which are strings or "something else". If the application does not need namespaces, it should well use a parser which makes no assertions about the content of a name, other than (perhaps) that it contain no more than one colon. If, on the other hand, the application operates on a dom-like model, unless the application is "about" namespaces, then it is not necessary that any part of the application know about namespaces except that part which decodes and encodes objects. which part is the interface to the parser - and the only interface to the parser. Since, in that case the part of the "application" which handles namespaces is effectively inseparable from the parser and, integral with it, from the point of view of such an application, an explicit layering has no advantage. This is, in any case, a minor issue. The model for names is the more significant issue. My experience is that, if the application performs operations (a) on a document model which (b) require that it observe namespaces, then it is going to perform comparisons over collections of (at least) element names and attribute names, and that these collections constitute a structured store, not temporary operands for comparisons "on the fly". Once this is true, then it is more effective for the parser to have interned the name at the point where it was parsed and to pass such interned names through its interface to/from the application, than it is for it to pass strings. The names are interned into collections which, in turn, are identified by uri. This mechanism puts the application in the position to 1) perform comparisons as an identity comparison rather than a string compare; 2) cache additional information (eg the dtd, the uri, the prefix at the time interned, ...) directly on the interned name; 3) avoid having to manage element-specific prefix bindings - as is, for example, suggested in the latest xsl draft. (for those following the namespace discussion, this was the "indefinite extent" issue which I raised in one of my six questions.) > > ... > > I think the main question I have is, will the namespaces draft ever > eventually be integrated into a future draft of XML, e.g. XML 1.1? > This does not change the arguments above. 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
|
|||||||||
