Re: Appling inheritance rule to xml:base, was Re: FINAL minutes for the XML

On Mon, Mar 06, 2006 at 02:39:48AM +0000, Henry S. Thompson wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I wasn't at the f2f, for which apologies, but I find myself made
> uneasy by the proposal to retain 'inheritance' of xml:base.  As you

  Same here. It means silent breakage of the document at canonicalization
time, this must be avoided.

> say, this doesn't always give the 'right' results.  What I find
> frustrating is that it's easy to state a strategy which _would_ always
> give the 'right' answer, namely:
> 
>  "Use the name *EII* for an element information item to be
>   canonicalized, and *EIIC* for the element information item
>   corresponding to *EII* in the result of parsing the canonical
>   serialization of the node-set containing *EII*.
> 
>  "Synthesize an xml:base attribute for *EII* iff the *EIIC*'s [base
>   URI] would otherwise be different from *EII*'s [base URI]."
> 
> This has the advantage that not only does it correctly produce
> 
> <a xml:base="http://example.org">
>        <c xml:base="test"/>
> </a>
> 
> from 
> 
> <a xml:base="http://example.org">
>    <b xml:base="test">
>        <c/>
>    </b>
> </a>
> 
> when <b>...</b> is filtered out, but it will _also_ correctly produce
> 
> <a xml:base="http://example.org">
>        <c xml:base="http://example.org/test/test"/>
> </a>
> 
> 
> from
> 
> <a xml:base="http://example.org">
>    <b xml:base="test">
>        <c xml:base="test"/>
>    </b>
> </a>
> 
> when <b>...</b> is filtered out.

  Note: I'm not sure the examples really convey what they should,
        if in the example we used <b xml:base="test/a"> then the
	composition would lead to  a test/test base on c, but as
	written I do think the composition is still 'test' in the result
	I assume John didn't tried to apply the computation from
	RFC2396 * manually or maybe the example we had at the f2f were
	misleading or broken. If all xml:base reference resources in the
	same "directory" basically the composition problem doesn't 
	appear in practice.
[*] or later

  Hum, assume you don't have a fixed base on a, then you force generating
a base depending on the document base,, which mean suddenly canonicalization
of a document depends on how you retrieved it (e.g. a file access would 
end up with file:///localpath/test/test while from a web access you would
get http://example.org/test/test , I don't think it's acceptable either.

> Can't we come up with a way to get this effect?

  I definitely prefer a solution leading to false negative i.e. we fail to
canonicalize in the same way, than a situation leading to false positive
where the canonicalization result in a broken result.
  We already discussed in the past especially with Richard generating
relative xml:base when possible, maybe we need to formalize this and 
put it as the algorithm to compute the canonicalized result.

Daniel

-- 
Daniel Veillard      | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
daniel@veillard.com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ |

Received on Monday, 6 March 2006 09:37:15 UTC