Re: Agenda for XML Core WG telcon of 2012 October 3

Daniel Veillard <veillard@redhat.com> writes:
>  Suppose I want to implement XInclude 1.1 in libxml2, and that I'm
> handled:
>
>    <xi:xinclude parse="texte" href="data.txt">
>      <xi:fallback ..../>
>    </xi:xinclude>
>
>  That could be an intended XInclude 1.0 text inclusion, but the french
> author mistyped that to be "texte", or that could be an XInclude 1.1
> inclusion for a parse value not supported by my XInclude 1.1
> implementation.
>
>  The problem is that the behaviour for both is completely different,
> in one case it is a fatal error, in the other case i should look at the
> fallback.
>  How can we have a clear behaviour without any versioning ?

I thought about that too. I concluded that the problem wasn't really
that significant in practice.

There are no existing XInclude 1.0 documents for which the behavior is
different. XInclude 1.1 will accept some documents that would be
erroneous in XInclude 1.0 (if the user provided fallback). A 1.0
processor will reject some documents that would be valid in XInclude
1.1.

Consider your example:

A 1.0 processor will report a fatal error. Users will notice.

A 1.1 processor will fallback, if there is fallback (in my experience
there rarely is). The user will (probably?) notice. If there's no
fallback, the processor will report a fatal error.

I wouldn't object to versioning if I could think of some practical,
lightweight approach.

We *could* use a new namespace, but...ugh...that means I can't write
documents that will work with both 1.0 and 1.1 processors. That seems
like a showstopper. I guess we could say that a 1.1 processor must
accept xi:include elements in the 1.0 namespace and that users must
use the 1.1 namespace to get new features, but...ugh...*two*
namespaces for XInclude in the same document?

We *could* provide a version attribute. We could require version=1.1
for 1.1 features but that's a going to be a real PITA for users.
Not quite as bad as a new namespace, I guess, but...

On balance, I don't think it's worth it.

>  I'm also worried on the fact that we are dropping interoperability
> for any parse value different from "text" or "xml", this is just
> defined as implementation dependant. 

"Defined" not "dependent".

> It would be a bit like if the
> URI spec said that the implementation of URI handling 'protocol' part
> is 'implementation dependant', no it is defined in specifications
> outside of the URI RFC, but they are not 'implementation dependant'.

Sure they are. What's the spec for ical:, for itunes:, for gnome:
etc. Heck, some systems let you define protocol handlers for your
own protocols.

>   Actually switching the parse values outside of "xml" and "text"
> to be actual Mime Types (defined in RFC 1521 ?) would make the detection
> of a typo on the parse value immediate, and still allow an fatal error
> to be raised on an 1.1 implementation.

I considered that, in fact, but it felt like more than was necessary.
(I don't really think there will be many new parse= values in
practice, allowing extra ones is mostly a way of avoiding having to
rev the spec again if someone figures out a new one ten years from
now.)

>   So my suggestion would be to try to hook the new parse values to
> the existing mime types, suggest interpretation of fragid should be
> associated to the indicated mime type, and then we have a framework
> which would still drive implementations toward interoperability.

I can totally sign up for saying that parse must be "xml", "text" or a
MIME content type.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh
Lead Engineer
MarkLogic Corporation
Phone: +1 512 761 6676
www.marklogic.com