XOM API for Processing XML with Java

["Michael Kay" <mike AT saxonica.com>]

I agree with you entirely about the awfulness of namespaces (I wish I could
find the posting where I claimed the design was so bad it would never catch
on). But we can't rewrite history, and namespaces-in-content were an
inevitable development.

However, I do think that the XPath model for namespaces, (which exposes only
the "inscope namespaces" for an element and hides "declared namespaces") is
a better solution. Its advantage is that it makes things much cleaner for
the user, and puts all the burden of managing the complexity on the
implementor. When you copy an element, it takes all its in-scope namespaces
with it, so you don't have to worry about where the namespaces were declared
- and it seems to me entirely in keeping with the namespaces Rec that you
shouldn't have to worry about where a namespace was declared, so long as
it's in scope. This also means that the task of eliminating
duplicate/redundant declarations falls entirely on the system, not on the
user. (If declared namespaces are significant, then declarations can never
be considered redundant.)

Whether detaching/copying is an expensive operation depends on the
implementation. I don't think it's particularly expensive in Saxon given a
typical scenario where the number of in-scope namespaces rarely exceeds half
a dozen. It's more expensive of course when you implement Saxon or any other
XSLT/XQuery engine on top of XOM, because the models are mismatched. And I
think that if people expect the namespace bindings of the new location to
rule, they've simply not understood the model. 

Michael Kay
http://www.saxonica.com/

> -----Original Message-----
> From: xom-interest-bounces AT lists.ibiblio.org 
> [mailto:xom-interest-bounces AT lists.ibiblio.org] On Behalf Of 
> Elliotte Harold
> Sent: 06 February 2006 00:23
> To: peter murray-rust
> Cc: xom-interest
> Subject: Re: [XOM-interest] Scope of namespaces
> 
> peter,
> 
> You've hit a major flaw in namespaces. There's nothing XOM can do to 
> solve this. Any solution we follow including the current one 
> has nasty, 
> surprising consequences for some use cases. The simple fact is that 
> namespace prefixes in attribute values are evil, and will cause 
> problems, no matter which API you use, no matter how you 
> treat them. Sad 
> but true.
> 
> We went around and around on this issue (in scope vs. 
> declared) a couple 
> of years ago, and there just doesn't seem to be a good way 
> around it. I 
> eventually decided that the least surprising approach was 
> that detached 
> elements would not automatically carry with them the 
> namespace bindings 
> of their ancestors. Doing so would:
> 
> 1. Make detaching a very expensive operation
> 
> 2. Surprise people who expected the namespace bindings of the new 
> location to rule
> 
> This is especially true if you consider that it's not just 
> the presence 
> but the absence of bindings for a particular prefix you have 
> to consider.
> 
> I wish I had a better answer for you, but there's just no way around 
> this ugliness in namespaces. All I can suggest is remove the 
> prefixes in 
> attribute values if possible and if not then make sure you always use 
> the same prefixes.
> 
> -- 
> ?Elliotte Rusty Harold  elharo AT metalab.unc.edu
> XML in a Nutshell 3rd Edition Just Published!
> http://www.cafeconleche.org/books/xian3/
> http://www.amazon.com/exec/obidos/ISBN=0596007647/cafeaulaitA/
ref=nosim
> _______________________________________________
> XOM-interest mailing list
> XOM-interest AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/xom-interest
>