- From: James Sulak <jsulak@gmail.com>
- Date: Tue, 4 May 2010 13:52:38 -0500
- To: Romain Deltour <rdeltour@gmail.com>
- Cc: xproc-dev@w3.org
Well, as I predicted, I stand corrected. :) I thought the whole implied namespace binding would give just enough wiggle room to make xproc treat them as actual attributes (like the DTD wants to), but apparently not. On Tue, May 4, 2010 at 1:15 PM, Romain Deltour <rdeltour@gmail.com> wrote: >> 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] http://www.w3.org/TR/xproc/#err.C0059 > [err:XC0062] http://www.w3.org/TR/xproc/#err.C0062 > > 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 http://www.w3.org/2000/xmlns/. >> 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 http://www.w3.org/2000/xmlns/, 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] http://www.rpbourret.com/xml/NamespacesFAQ.htm#dtd_6 >> [2] http://www.w3.org/TR/REC-xml-names/ >> >> -James >> >> >> >> On Tue, May 4, 2010 at 11:09 AM, HILLMAN, Tomos <tomos.hillman@oup.com> >> 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:53:33 UTC