Re: XInclude namespace issue draft response [was: Minutes for XML Core WG telcon of 2015 February 18]

Please review and reply before this week's telcon at
which time I plan to send out this reply (and, soon
thereafter, request transition of XInclude 1.1 to CR).

paul

On 2015-02-20 09:07, Paul Grosso wrote:
>
> On 2015-02-18 10:59, Paul Grosso wrote:
>>
>
>>>
>>> Eric van der Vlist (via Norm) asks what the post-XInclude infoset
>>> is for this element:
>>>
>>> <xi:include xmlns:my="MYNAMESPACE"
>>> href="mydoc.xml" fragid="element(foo)"
>>> my:root="true"/>
>>>
>>> when mydoc.xml is:
>>>
>>> <doc xmlns:my="YOURNAMESPACE">
>>>   <my:note xml:id="foo">
>>> <my:x/>
>>> </my:note>
>>> </doc>
>>>
>>> Paul suggested it would be
>>>
>>>   <my:note xml:id="foo" my2:root="true" xmlns:my="YOURNAMESPACE" 
>>> xmlns:my2="MYNAMESPACE">
>>> <my:x/>
>>> </my:note>
>>>
>>> where the "spelling" of the prefix "my2" is implementation dependent?
>>>
>>> What do others think, and can we find an answer in the spec?
>>>
>>
>> Henry agrees with Paul that we are including infosets,
>> not text, so Paul's solution is fine.  He points out
>> that this isn't an infoset problem, it's just a
>> serialization issue--what prefixes to use for the
>> various namespaces, but what matters in the infoset
>> is the value of the namespace property, not the prefix.
>>
>> We still need to look at the spec to see if it's clear
>> (or at least doesn't say something to the contrary).
>>
>> Jirka says we should check section 4.3.  Henry says
>> there it talks about qualified names which has to do
>> with local names and namespace URIs, no prefixes involved.
>>
>> We will check with Norm to see what he says, and then
>> Paul will write a response.
>>
>
> Here's my draft response--please comment.  Especially
> comment on whether you feel we should add some (minor)
> wording/Note to XInclude 1.1 as we go to CR:
>
>
> Regarding the example in the comment at [0], the resulting
> infoset is clearly:
>
> <{YOURNAMESPACE}:note xml:id="foo" {MYNAMESPACE}:root="true">
>     <{YOURNAMESPACE}:x/>
> </{YOURNAMESPACE}:note>
>
> The only complication comes when trying to serialize this infoset.
>
> (Note also the discussion in the Infoset spec about "Synthetic
> Infosets" [1] and also the comments in XInclude's section on
> Namespace Fixup [2].  See also the analogous discussion of
> adding namespace declarations in the XSLT Recommendation [3].)
>
> When serializing this infoset, the namespace prefixes emitted by
> the XInclude implementation are implementation dependent.  See the
> fourth paragraph under section 4.7 "Creating the Result Infoset"
> at [4] where it says:
>
>  Some processors may not be able to represent an element's
>  in-scope namespaces property if it does not include bindings
>  for all the prefixes bound in its parent's in-scope namespaces.
>  Such processors may therefore include additional namespace
>  bindings inherited from the include parent in the in-scope
>  namespaces of the included items.
>
> We could perhaps either augment the above paragraph or the
> Namespace Fixup section to make an explicit reference to the
> case where prefixes may need to be modified to avoid emitting
> namespace declarations with the same prefix and different
> namespace names, but in my opinion, that behavior is already
> implied by the existing wording of the spec.
>
> For example, one reasonable serialization of the infoset
> resulting from the example in question might be:
>
> <my:note xml:id="foo" my2:root="true"
>          xmlns:my="YOURNAMESPACE" xmlns:my2="MYNAMESPACE">
>   <my:x/>
> </my:note>
>
> paul
>
> [0] {eventual URL of the comment in the www-xml-xinclude-comments list}
> [1] http://www.w3.org/TR/2004/REC-xml-infoset-20040204/#intro.synthetic
> [2] http://www.w3.org/TR/2014/WD-xinclude-11-20141216/#namespaces
> [3] http://www.w3.org/TR/xslt#section-XML-Output-Method
> [4] http://www.w3.org/TR/2014/WD-xinclude-11-20141216/#creating-result
>