Re: Error in merlin-iaikTests-two.tar.gz?

Hi Merlin,

No, that can't be. That's strange. For instance, the exclusive c14n spec 
[1] tells me that subset c14n by selecting elem2 in this document

<n0:local xmlns:n0="foo:bar"
          xmlns:n3="ftp://example.org">
<n1:elem2 xmlns:n1="http://example.net"
          xml:lang="en">
<n3:stuff xmlns:n3="ftp://example.org"/>
</n1:elem2>
</n0:local>

results in this:

<n1:elem2 xmlns:n0="foo:bar"
          xmlns:n1="http://example.net"
          xmlns:n3="ftp://example.org"
          xml:lang="en">
<n3:stuff></n3:stuff>
</n1:elem2>

Given the interpretation below, the xml:lang="en" would have to be also in 
the n3:stuff element. And it isn't. So I would (again) say that the first 
reference of merlin-iaikTests-two.tar.gz is wrong.

Christian


[1] http://www.w3.org/Signature/Drafts/xml-exc-c14n

--On Donnerstag, 23. Mai 2002 15:23 +0100 merlin <merlin@baltimore.ie> 
wrote:

>
> Hi Christian,
>
> I believe you're right. I think it's just a small oversight in
> the spec that we'll have to live with. Exclusive c14n doesn't
> seem to have this feature.
>
> Merlin
>
> r/geuer-pollmann@nue.et-inf.uni-siegen.de/2002.05.23/16:10:27
>> Hi Merlin,
>>
>> OK, I understood the writing. But now a question. Given the following
>> document. The document subset is formed of the C and E element (//C |
>> //E).
>>
>> <a xml:a="xmla">
>> <b>
>> <C xml:C="xmlC">
>> <d xml:d="xmld">
>> <E>
>> </E>
>> </d>
>> </C>
>> </b>
>> </a>
>>
>> Is the result after c14n this one? I read the c14n spec so:
>>
>> <C xml:a="xmla" xml:C="xmlC">
>> <E xml:a="xmla" xml:C="xmlC" xml:d="xmld">
>> </E>
>> </C>
>>
>> That's really strange. Intuitively, I'd guessed:
>>
>> <C xml:a="xmla" xml:C="xmlC">
>> <E xml:d="xmld">
>> </E>
>> </C>
>>
>> Christian
>>
>> --On Donnerstag, 23. Mai 2002 14:24 +0100 merlin <merlin@baltimore.ie>
>> wrote:
>>
>>>
>>> Hi Christian,
>>>
>>> This is a feature of the c14n spec; see the second paragraph
>>> of 2.4:
>>>
>>>   The processing of an element node E MUST be modified slightly when an
>>>   XPath node-set is given as input and the element's parent is omitted
>>>   from the node-set. The method for processing the attribute axis of an
>>>   element E in the node-set is enhanced. All element nodes along E's
>>>   ancestor axis are examined for nearest occurrences of attributes in
>>>   the xml namespace, such as xml:lang and xml:space (whether or not
>>>   they are in the node-set). From this list of attributes, remove any
>>>   that are in E's attribute axis (whether or not they are in the
>>>   node-set). Then, lexicographically merge this attribute list with the
>>>   nodes of E's attribute axis that are in the node-set. The result of
>>>   visiting the attribute axis is computed by processing the attribute
>>>   nodes in this merged attribute list.
>>>
>>> This probably isn't aesthetically ideal; however, it doesn't
>>> cause any problems.
>>>
>>> Merlin
>>>
>>> r/geuer-pollmann@nue.et-inf.uni-siegen.de/2002.05.23/14:45:23
>>>> Hi Merlin,
>>>>
>>>> I have a problem to verify your signature.xml from
>>>> merlin-iaikTests-two.tar.gz which was for testing exclusive c14n: The
>>>> first  Reference (digest input in c14n-0.xml) seems to be wrong. The
>>>> others can be  verified. It looks like this (indentation added by me):
>>>>
>>>> - c14n-0.xml -----------------------
>>>>
>>>> <Parent xml:foo="bar"
>>>>        xml:fool="barbar"
>>>>        xml:lang="en"
>>>>        xml:space="default">
>>>>
>>>> <GrandChild xml:foo="barbarossa"
>>>>            xml:fool="barbar"
>>>>            xml:lang="ge"
>>>>            xml:space="preserve"></GrandChild>
>>>>
>>>> </Parent>
>>>> ----------------------------------
>>>>
>>>> This reference was simply the XPath transform (and implicit inclusive
>>>> c14n  omitting comments). What I see is that both the Parent and the
>>>> GrandChild  have a xml:fool="barbar" attribute while the GrandChild
>>>> shouldn't.
>>>>
>>>> Regards,
>>>> Christian
>>
>
>
> -------------------------------------------------------------------------
> ---- The information contained in this message is confidential and is
> intended for the addressee(s) only.  If you have received this message in
> error or there are any problems please notify the originator immediately.
> The  unauthorised use, disclosure, copying or alteration of this message
> is  strictly forbidden. Baltimore Technologies plc will not be liable for
> direct, special, indirect or consequential damages arising from alteration
> of the contents of this message by a third party or as a result of any
> virus being passed on.
>
> This footnote confirms that this email message has been swept for Content
> Security threats, including computer viruses.
> http://www.baltimore.com
>

Received on Thursday, 23 May 2002 16:17:38 UTC