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

On Wed, Oct 03, 2012 at 08:31:40AM -0500, Norman Walsh wrote:
> 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.

  To be honnest I though about that too, except adding an optional
option attribute I don't see well how to cope with that simply

> We *could* use a new namespace, but...ugh...that means I can't write

  I discarded that as insane in practice :-)

> 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?

  yeah, using namespace for versionning is an especially klunky
  mechanism !

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

  unless there is someone with a smart idea :-)

> >  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".
> 
[ ... ]

Okay my example wasn't cleanly picked.

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

  I would love that too. It just raise some extra work:
    - change the production for the attribute value (reference to
      an adequate RFC or internal new productions)
    - clarification of unadequate value for parse still being a
      fatal error.
    - proper references added (is that IETF or IANA I can't remember)
    - maybe close a potential loophole stating that text/plain
      is equivalent to text and the XML mimetypes are equivalent to
      "xml"

 I'm sorry, I'm on vacation, on an island, the power actually went off
and I'm running out of battery, and the call is at 11:30pm ... I may
miss the call, sorry about that, as I really want to get back to an
active status on the group !

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 Wednesday, 3 October 2012 13:49:15 UTC