Re: FW: Clarification sought re C14N11

Hi Konrad,

Very good example, but I'm not sure I understand the rationale behind 
fixing it:

 > Now, please consider the following example.
 >
 > <e1 xml:lang="de" xml:base="http://www.example.org">
 >   <e2>
 >     <e3>
 >       <e4/>
 >     </e3>
 >   </e2>
 > </e1>
 >
 > With <e2> being omitted this would result in
 >
 > <e1 xml:lang="de" xml:base="http://www.example.org">
 >   <e3 xml:lang="de" (xml:base="http://www.example.org")>
 >       <e4/>
 >     </e3>
 > </e1>

I agree that it would be much better if xml:lang was not inherited in 
the e3 element, but I don't understand how this is related to xml:base 
fixup.

I would suggest that simple inheritable attributes should be handled 
like namespace attributes; that is there should be an additional 
condition that says something like the following:

"A simple inheritable attribute in the xml namespace is ignored if the 
nearest ancestor element of E's parent element that is in the node-set 
has an attribute in the node-set with the same name."

Maybe this text needs to be in section 2.3 in the Attribute Nodes section.

Even with the suggested fix to section 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.


... I think you can still end up with redundant redeclarations when 
there is more than one element in the node-set with an omitted parent 
and some common ancestor contains a simple inheritable attribute.

What do you think?

--Sean

Konrad Lanz wrote:
> Dear all,
> 
> I searched the list archive, and found the first draft for section 2.4
> in June 2006 [4]. Unfortunately I cannot exactly recall the intention of
> that change. Nonetheless, looking at it today and todays wording of the
> xml:base fix up, it makes perfect sense to revert this change.
> 
>> The relevant change is in section 2.4, where the language was changed
>> from:
>>
>> 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.
>>
>> to:
>>
>> The processing of an element node E MUST be modified slightly when an
>> XPath node-set is given as input and some of the element's ancestors
>> are omitted from the node-set.
> 
> Thus, may I propose to do this fix together with the feedback from CR
> Testing ?
> 
> Looking at the current text of c14n 1.1 the reverting should not harm
> the processing of xml:base. It says
> 
> "... ancestor axis contains successive elements E1...En that are omitted
> and E=En+1 is included"
> 
> implying that the parent (En) has been omitted.
> 
> 
> There is however a second point I'd like to discuss here, which needs
> some introduction and an example:
> 
> [4] was focused on the xml:base fix-up and hence lacked an update to the
> ancestor axis examination step for simple inheritable attributes
> 
> cf.: "This examination is performed until the first rendered occurrence
> exclusive ..."
> 
> As far as I recall intended to fix the idiosyncrasy of unnecessary
> copying of inheritable xml:base attributes in c14n.
> 
> Now, please consider the following example.
> 
> <e1 xml:lang="de" xml:base="http://www.example.org">
>   <e2>
>     <e3>
>       <e4/>
>     </e3>
>   </e2>
> </e1>
> 
> With <e2> being omitted this would result in
> 
> <e1 xml:lang="de" xml:base="http://www.example.org">
>   <e3 xml:lang="de" (xml:base="http://www.example.org")>
>       <e4/>
>     </e3>
> </e1>
> 
> (xml:base="http://www.example.org") is written in parenthesis to show
> that it wouldn't appear in c14n 1.1 .
> Without (xml:base="http://www.example.org") it should be the result
> according to the text in c14n 1.0 .
> 
> The following however would be more natural and may be an option for
> future versions of c14n.
> 
> <e1 xml:lang="de" xml:base="http://www.example.org">
>   <e3>
>       <e4/>
>     </e3>
> </e1>
> 
> The XML Security Maintenance Group might want to change this
> idiosyncrasy in a version post c14n 1.1 .
> 
> Keeping this idiosyncrasy in both versions C14n 1.0 and 1.1 however
> remains compatibility for documents not using xml:base or xml:id.
> 
> But then a question of consistency arises and we may want to have
> xml:base also being copied into an orphan. Just to be consistent with
> the other attributes in the xml namespace although it is not really
> necessary.
> 
> This may result in the following sentence being removed from the
> current c14n 1.1 text.
> 
>> Then fix-up is only performed if at least one of E1 ... En has an
>> xml:base attribute.
> 
> Assuming others also feel it's worth to achieve consistency here, may I
> propose to consider such a change also as a result from CR-Testing ?
> 
> Any Thoughts?
> 
> Konrad
> 
> Grosso, Paul schrieb:
>> Forwarding to XML Core with permission.
>>
>> paul
>>
>> -----Original Message----- From: Thomas Roessler [mailto:tlr@w3.org]
>>  Sent: Tuesday, 2007 August 21 10:55 To: Grosso, Paul;
>> Norman.Walsh@Sun.COM Cc: w3c-xml-cg@w3.org; Sean.Mullan@Sun.COM 
>> Subject: Clarification sought re C14N11
>>
>> Paul, Norm,
>>
>> Sean Mullan (CCed) noticed [3] that the C14N 1.1 CR [1] can be read 
>> in a way that would copy inheritable attributes to all children of an
>> element if that element's parent have been removed. That behavior 
>> would be different from the one in C14N 1.0 [2].
>>
>> The relevant change is in section 2.4, where the language was changed
>> from:
>>
>> 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.
>>
>> to:
>>
>> The processing of an element node E MUST be modified slightly when an
>> XPath node-set is given as input and some of the element's ancestors
>> are omitted from the node-set.
>>
>> We are wondering whether this is an intentional change, and the 
>> behavior sketched at [3] is desired, or whether this was an 
>> inadvertent change, and the text is meant to describe the behavior 
>> known from C14N 1.0.  Preliminary discussion seems to suggest that 
>> people are leaning toward the latter interpretation; in that case, it
>> might be worth cleaning up the text while considering CR feed-back.
>>
>> Your guidance would be most welcome, to ensure that the right kind of
>> guidance is provided to implementors in preparation for the interop
>> event.
>>
>> 1. http://www.w3.org/TR/2007/CR-xml-c14n11-20070621/ 2.
>> http://www.w3.org/TR/xml-c14n 3. 
>> http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Aug/0049.h
>>  tml
>>
>> Regards,
> 
>

Received on Wednesday, 22 August 2007 14:46:13 UTC