W3C home > Mailing lists > Public > www-xml-xinclude-comments@w3.org > October 2004

Hidden errors

From: Elliotte Harold <elharo@metalab.unc.edu>
Date: Fri, 15 Oct 2004 11:54:53 -0400
Message-ID: <416FF2CD.8060701@metalab.unc.edu>
To: www-xml-xinclude-comments@w3.org

I think this is covered by the spec, but it's not covered by the test 
suite, and I wanted to check my interpretation before submitting a test 
to cover this. What happens if there's a fatal error hidden inside an 
unactivated fallback? For instance, in this example assume the file 
utf8.xml is found and parsed correctly, but note the parse="nonesuch" 
deeper inside:

<test xmlns:xinclude="http://www.w3.org/2001/XInclude">
   <xinclude:include href="utf8.xml" parse="text">
       Not activated because the top level element succeeds.
       <xinclude:include href="utf8.xml" parse="nonesuch">

I think this is still a fatal error the XInclude processor should 
report; i.e. it should not accept this document. Perhaps the spec could 
be a little clearer about that though.

Hmm, maybe things aren't so clear. Section 5.2 says that a conforming 
application "stops processing when a fatal error is encountered." What 
does it mean to "encounter" a fatal error? Does it encounter the error 
in the parse attribute if it never actually uses the parse attribute?

It's not only the parse attribute that's at issue here. There are other 
ways we could cook up fatal errors inside an unactivated fallback: href 
attributes that contain fragment IDs, xpointer attributes that use 
percent escaping, and more.

Elliotte Rusty Harold  elharo@metalab.unc.edu
XML in a Nutshell 3rd Edition Just Published!
Received on Friday, 15 October 2004 15:54:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:09:35 UTC