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