> >I thought that XPath caveat was weird as well,
>
>I don't think that it is weird. If we define the processing rules over
>node-sets, we replace some nodes in a node-set with ones in the other
>node-set. It looks easy, but is not possible because, according to the
>XPath spec, a node-set is defined as a set of nodes in a document tree.
>That is, it is because the relation between node-sets from distinct
>document trees is not defined. So we defined the processing rules over
>octet streams. Does this make sense?
Yes, actually -- explained that way it makes perfect sense, thanks. In
practice, it may be possible to recombine node-sets using a particular
implementation, but formally the idea is undefined in XPath, so it must be
excluded from processing rules specified in the context of XPath.
> >Since <Bar>'s namespace is in scope for the first element of the input
> >node-set, <Foo>, parsing context C is {xmlns:baz="http://example.org/baz",
> >xml:something="other"}.
>
>Sorry for confusing you. The text defining the parsing context should be
>tweaked. In this case, C is {xmlns:baz="http://example.org/baz"}. Please
>consider the meaning of the word "parsing context".
I see -- so C is defined as containing "each namespace that is in scope for
the first element node in X", but not namespaces that are first declared in
that element itself?
> >So the result of wrapping would be:
> >
> ><dummy xmlns:baz="http://example.org/baz" xml:something="other"><Foo
> >xml:something="other" Id="foo">
> ><plaintext />
> ></Foo></dummy>
>
>The result would be:
>
><dummy xmlns:baz="http://example.org/baz"><Foo xml:something="other" Id
>="foo">
> <plaintext />
></Foo></dummy>
Canonicalization after parsing and unwrapping removes the extra
'xml:something-"other"' declaration, so the end result is the same, I
think. Might there be examples where the end result would be different?
> >Parsing, unwrapping and canonicalizing would result in:
> >
> ><Foo xmlns:baz="http://example.org/baz" xml:something="other" Id="foo">
> > <plaintext />
> ></Foo>
Thank you for the explanations.
Ari Kermaier arik@phaos.com
Senior Software Engineer
Phaos Technology Corp. http://www.phaos.com/