Re: [xml-dev] XML processor behavior with unused NS declarations

[Evan Lenz <evan@evanlenz.net>]

I would use the criterion of whether its presence is indistinguishable 
in the XPath 2.0 data model (XDM as Michael Kay mentioned). Accordingly, 
I would tend to only permit the first adjustment and not the second, 
since by that standard, the use of the "otherex" prefix in the element's 
QName *is* substantive and shouldn't be rewritten. Interestingly, this 
wasn't the case in the XPath 1.0 data model. If multiple namespace nodes 
for the same namespace URI appear on an element in that namespace, there 
was no way of knowing which prefix was actually used in the element's 
QName in the XML instance[1]. That changed in 2.0; prefixes are 
considered significant now too.[2] Of course, you should never write 
*application code* that depends on particular prefixes being used. And 
given that, despite the criterion I'm recommending, I'm not sure I can 
think of any examples where something would actually break due to 
changing "otherex" to "ex" in the start tag in your example, perhaps 
some test code that performs diffs on reports of names used or something 
like that...but that's a stretch. I guess my point is that we can refer 
to a common spec to resolve these questions, rather than address them 
piecemeal.

Evan

[1] http://www.w3.org/TR/xpath#dt-expanded-name
[2] http://www.w3.org/TR/xpath-datamodel/#dt-expanded-qname

Jim Tivy wrote:
> Yes, absolutely a different situation but one that might fall under
> someone's concept of "redundant" declaration.  Consider the following
>
> <foo 
>    xmlns:ex="http://example.com";  
>    xmlns:otherex="http://example.com"; 
>    xmlns:unused="http://example.com>
>   <ex:bar xmlns:ex="http://example.com";>
>     <otherex:bat/>
>   </ex:bar>
> </foo>
>
> What kinds of things should a processor/serializer team allow to happen?
>
> My answer would be:
>
> Yes - remove namespace decl in <ex:bar xmlns:ex="http://example.com";> (your
> example)
>
> Yes - change  <otherex:bat xmlns:ex="http://example.com"/> to <ex:bat..
>
> Don't remove any of the namespace decls in <foo tag.
>
> And users should be ready for any variation of the Yes changes including
> none as well as decorating every element or creative default scoping. 
>
>
>
> -----Original Message-----
> From: Evan Lenz [mailto:evan@evanlenz.net] 
> Sent: Thursday, July 23, 2009 10:25 PM
> To: Jim Tivy
> Cc: 'Chuck Bearden'; xml-dev@lists.xml.org
> Subject: Re: [xml-dev] XML processor behavior with unused NS declarations
>
> It sounds like you're referring to a different scenario ("a yet unused 
> namespace declaration"). I'm talking about a repeat of the exact same 
> URI/prefix binding in a location where it's already in scope. For example:
>
> <foo xmlns:ex="http://example.com";>
>   <bar xmlns:ex="http://example.com";>
>     <bat xmlns:ex="http://example.com"/>
>   </bar>
> </foo>
>
> Have you ever come across a scenario where the second two "ex" namespace 
> declarations could not be safely removed? Canonicalization removes the 
> latter two, and it *should* always be safe for a generic 
> (namespace-aware) XML processor to remove them. On the other hand, it 
> should never remove the first (even though it's unused). Also, if 
> another declaration bound the same URI to the "ex2" prefix, that should 
> never be removed. It would *not* be redundant in the sense I mean, since 
> it uses a different prefix.
>
> There's also the advantage of exposing brittle hacks earlier rather than 
> later. Yes, I would argue that hacks relying on the presence of either 
> of the latter two namespace declarations in the above example should not 
> be condoned, because they'll likely break if you switch to another 
> (fully conformant) processor. Just like a hack that depended on 
> attribute order, they'll break sooner or later.
>
> In the example you cited ("there could only be one prefix declared for a 
> given namespace url"), I can see where stripping declarations as a 
> consequence of that arbitrary restriction would be bad. But I'm not 
> suggesting those can be safely stripped (quite the opposite).
>
> Evan
>
>
> Jim Tivy wrote:
>   
>> Hi Evan
>>
>> Ideally an Xml processor should not throw away any namespace declarations
>> reduntant or not since sometimes people hack things into serializations
>> depending on a yet unused namespace declaration.
>>
>> The apache serializer - now deprecated had a restriction where there could
>> only be one prefix declared for a given namespace url, so it dropped
>> redundant declarations that someone was depending on for some downstream
>> processing.  I realize you can argue the downstream processing should not
>> rely on the upstream declaration - but hacks often make things work.
>>
>> Jim 
>>
>>
>> -----Original Message-----
>> From: Evan Lenz [mailto:evan@evanlenz.net] 
>> Sent: Wednesday, July 22, 2009 2:15 PM
>> To: Chuck Bearden
>> Cc: xml-dev@lists.xml.org
>> Subject: Re: [xml-dev] XML processor behavior with unused NS declarations
>>
>> Hi Chuck,
>>
>> Sorry to be late to this thread. It sounds like you've gotten your 
>> answer already: don't throw the namespace declaration away. If you're 
>> interested in reading some more discussion/background on the reasons 
>> why, check out the "QNames in Content" section of a paper/chapter I 
>> wrote called "Understanding XML Namespaces".[1]
>>
>> Of course, it's always safe to throw away *redundant* namespace 
>> declarations when serializing XML, provided you're not just serializing 
>> a fragment (in which case it wouldn't be redundant anymore). For 
>> example, if the <h2> element in your example merely repeated the 
>> xmlns:dc declaration verbatim, it would be safe to leave that out of 
>> your serialized result. (And Canonical XML *requires* such superfluous 
>> namespace declarations to be removed.) You just can't make any removals 
>> that would make a difference to the XPath data model's abstraction of 
>> your document.
>>
>> Evan Lenz
>> Lenz Consulting Group
>>
>> [1] http://lenzconsulting.com/namespaces/#qnames_in_content
>> [2] http://www.w3.org/TR/xml-c14n#SuperfluousNSDecl
>>
>>
>> Chuck Bearden wrote:
>>   
>>     
>>> Is a namespace-aware XML processor permitted to drop a namespace 
>>> declaration when no elements or attributes in that namespace are used 
>>> within the scope of the declaration?  Say, given this example from the 
>>> RDRa Primer:
>>>
>>>   <div xmlns:dc="http://purl.org/dc/elements/1.1/";>
>>>      <h2 property="dc:title">The trouble with Bob</h2>
>>>      <h3 property="dc:creator">Alice</h3>
>>>      ...
>>>   </div>
>>>
>>> there's no danger of the processor dropping the 'xmlns:dc' 
>>> declaration, correct?
>>>
>>> I looked at the Namespaces in XML recommendation, and it doesn't 
>>> mention omitting them.  A namespace-unaware processor would treat NS 
>>> declarations like attributes and hence not drop them, so I reckon that 
>>> a NS-aware processor should match that behavior as well, but 
>>> confirmation from the cognoscenti is welcome!
>>>
>>> Thanks
>>> Chuck
>>>     
>>>       
>> _______________________________________________________________________
>>
>> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
>> to support XML implementation and development. To minimize
>> spam in the archives, you must subscribe before posting.
>>
>> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
>> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
>> subscribe: xml-dev-subscribe@lists.xml.org
>> List archive: http://lists.xml.org/archives/xml-dev/
>> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>>
>>
>>
>>
>> _______________________________________________________________________
>>
>> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
>> to support XML implementation and development. To minimize
>> spam in the archives, you must subscribe before posting.
>>
>> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
>> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
>> subscribe: xml-dev-subscribe@lists.xml.org
>> List archive: http://lists.xml.org/archives/xml-dev/
>> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>>
>>   
>>     
>
>
>
>