Re: removing/adding xmlns:xxx attributes

A tentative workaround could be:

<p:declare-step version='1.0' xmlns:p="">
   <p:output port="result"/>

   <p:input port="source">
         <doc xmlns="" xmlns:law=" 

   <p:filter select="//d:chunk" xmlns:d=""  

   <p:viewport match="*/*" name>
     <p:namespace-rename from="" to=" 

   <p:namespace-rename from="" to=""></ 

   <p:namespace-rename from="" to=" 


The first namespace-rename (in the viewport) temporarily renames the  
'law' namespace to something else, to differentiate the namespace  
declarations in the children from the namespace declaration in the  
'chunk' parent.

The second namespace-rename removes the declaration from the 'chunk'  

The third namespace-rename restores the correct 'law' namespace to the  


Le 4 mai 10 à 20:15, Romain Deltour a écrit :

>> That said, it seems like it should be valid to specifically add (with
>> p:add-attribute) or match/delete (with p:delete) namespace  
>> declaration
>> attributes.
> I don't think namespace declarations should be considered as  
> attributes. By the way the p:add-attribute step cannot be used to  
> add namespace declarations (see [err:XC0059]), the same for the  
> p:delete (see [err:XC0062]).
> [err:XC0059]
> [err:XC0062]
> I assume the issue must be either dealt-with at serialization time  
> or you have to explicitly undeclare the "law" namespace on the  
> 'chunk' element, although I couldn't tell how to implement these  
> approaches...
> Romain.
> Le 4 mai 10 à 18:54, James Sulak a écrit :
>> Hi Tom,
>> Namespace cleanup is hard, especially when DTDs are involved.
>> My technical understanding of namespaces isn't the best, but I think
>> the root of the problem is that DTDs don't support namespaces
>> properly.  (For way too much detail, see [1].)  In an ideal world,  
>> DTD
>> validation wouldn't treat xmlns attributes as "real" attributes, and
>> you wouldn't have a problem.
>> That said, it seems like it should be valid to specifically add (with
>> p:add-attribute) or match/delete (with p:delete) namespace  
>> declaration
>> attributes.  From the namespace spec [2]:
>> "The prefix xmlns is used only to declare namespace bindings and is  
>> by
>> definition bound to the namespace name
>> It MUST NOT be declared . Other prefixes MUST NOT be bound to this
>> namespace name, and it MUST NOT be declared as the default namespace.
>> Element names MUST NOT have the prefix xmlns."
>> So if xmlns is implicitly bound to, I
>> would think that you could use the xmlns prefix to match the
>> attributes.  In that case, it would be a bug in the processor that  
>> you
>> can't.  But I'll leave it to more knowledgeable folks to tell me that
>> I'm wrong :)
>> [1]
>> [2]
>> -James
>> On Tue, May 4, 2010 at 11:09 AM, HILLMAN, Tomos < 
>> > wrote:
>>> Hi List,
>>> I'm wondering if anyone has a solution to the following problem:
>>> I'm writing a chunking script that takes one large document and  
>>> filters out particular 'chunks' - say //div1.  The document needs  
>>> to be valid against a declared DTD.
>>> The root element of the original document has an xmlns:law  
>>> attribute declaration for <law:extract> elements; these may also  
>>> occur multiple times within each 'chunk'.
>>> Unfortunately, although the xmlns:law attribute is allowed both on  
>>> the original root element and the law:extract element, it is not  
>>> allowed on the filtered elements by the DTD: however, this is  
>>> where my xproc processor (calabash under oxygen) adds them.
>>> How should I go about removing these attributes from the div1  
>>> elements and add them to the law:extract elements?  Trying to  
>>> treat the elements as simple attributes gives errors like 'xmlns  
>>> namespace not declared'...
>>> Help!
>>> Tom
>>> Oxford University Press (UK) Disclaimer
>>> This message is confidential. You should not copy it or disclose  
>>> its contents to anyone. You may use and apply the information for  
>>> the intended purpose only. OUP does not accept legal  
>>> responsibility for the contents of this message. Any views or  
>>> opinions presented are those of the author only and not of OUP. If  
>>> this email has come to you in error, please delete it, along with  
>>> any attachments. Please note that OUP may intercept incoming and  
>>> outgoing email communications.

Received on Tuesday, 4 May 2010 18:39:26 UTC