Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Vocabulary Combination and optional namespaces
 Bill de hÓra wrote: > > Arjun Ray wrote: > > > > | Paul Prescod: > > | And anyhow, it should be the responsibility of infrastructure to track > > | the namespace environment. XSLT is an example of infrastructure that > > | does a pretty good job. > > > > But your Python code was exposed to the problem even in the simple case. > > I'll grant that the changes were simple, but why did anything have to be > > changed at all? > > The programming problem boils down to this. In a non-namespaceed > world, XML elements are self-contained: > > elementname > > In other words, XML elements are strings, after a kind. In a > namespaced world, they are not: > > elementname, namespace, elementprefix > the programming problem is an artifact of the misconception that names in a namespaced world need be modeled at the application level as tuples. this is no more true than would be the claim that names in a non-namespaced world need to be modeled at the application level as unicode scalar value tuples. > In other words namespaced elements are tuples after a kind. if one insists on modeling them that way, one is making ones own problems. > You're > told to only care about the first two members, but sometimes you do > need to care about the prefix (that prefixes have no import is a > myth, because XPath makes it a myth) not if xpath expressions are parsed in the correct dynamic context. if the xml-dev archives are alive, i've posted notes on this topic (and that of qname decoding) way back when. > > For a direct example of how the structural issues of using a tuple > affect code, see the SAX startElement call, and try operating on > various bits of markup with a handler. For anyone that has Dave > Brownell's SAX book, he has a good discussion on this. Or go through > the xml-dev archives.. in this regard, maybe one should consider whether the sax interface and the sax processing model is all (or perhaps _is_) that one needs for working with namespaces. > > After that try programming with XPaths against namespaces - the sort > of code simplicity Paul is after will be awkward with XPaths. cl-xml includes a first cut xml-path processor. it adds to the standard parsing protocol that xml path expressions are interned in the parser's dynamic context. from that point on, the only aspects of the processor - and therefor of application code, which are concerned with lexical properties (prefixes, namespace names, local parts) are those which the xpath standard stipulates must be present - eg to match on local part or on namespace name only. everything else can be expressed in terms of abstract names. no tuples. no lexical properties. > Using > an XPath is almost always preferreable to rolling out yet another > DOM iterator or SAX stack or some hokey findByFoo API call - until > it comes to using namespaces, where managing embedded prefixes can > make a NodeList look decidely attractive. Try something like Xalan > or Pyana with and without namespaces to get an idea of the differences. > > All the while ask yourself, how to I manage this code with and > without namespaces? How do I get the code under control? no navigational code needs to be expressed differently "with and without" namespaces. if a given substrate requires that, then it is the wrong one for the task. > > In turns out that you can't without incurring a development cost. true, but only in that one would need to fix what appears to be an inappropriate document model. > After dealing with this stuff for the last few years, I believe that > cost isn't worth it, and where it might be worth it, it's proabably > for corner cases that have no business being generalized into the > bulk of programming work with XML. So naturally when I see someone > coming at me with document design using namespaces, I'm want to > resist that design in favour of something simple and cost-effective. > > There is no canonical (self-describing) form for for a namespaced > element, it must be that i do understand what this is intending to claim, as, as i do understand it, i have thousands of lines of code lying around here which disproves it. > ie there is no way to treat it like a regular XML name so > the code reflects the difference. You can't get to such a form for a > namespaced element for two reasons > > - technically the XML grammar won't allow it. please amplify. it is not clear how the grammar places this constraint on the model. > > - socially, it seems people don't want deal with URIs as element > names at the syntax level. there is no reason that they should have to. ... 
|
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
|
|||||||||
