XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
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
>
>   



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS