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

On Mon, Oct 01, 2012 at 11:12:39AM -0500, Paul Grosso wrote:
> NOTE:  I plan to request approval to publish our FPWD of XInclude 1.1
> at this telcon, so be sure to review it ahead of time and, if you
> aren't going to be on the call, email your thoughts.

  I can't guarantee to be on the call, it's vacation week in China
and we are supposed to have IP access from the hotel, but  there
is a risk that i won't be able to make it.

 I would say my main problem a an implementor when reviewing that
proposed version, is that we are introducing a rather severe change
in behaviour - especially on parse value - without any versioning
information.

 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'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. 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'.

  'implementation dependant' indicate the author can do whatever he
wants and be conformant. We should instead indicate that the parse
value be tied to a mime-type and that parsing and selection should
be following the standards provided for that Mime-type. We avoided
that generic description because we initially restricted to 2 hardcoded
kind of resources, but if we open the door to any kind of resource
we should give guidelines on ways to implement leading to
interoperability instead of chaos.

  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.

  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.

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

Received on Tuesday, 2 October 2012 05:44:36 UTC