[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Vocabulary Combination and optional namespaces

vocabulary re ie eg

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.



Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.