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

Re: Hidden errors

From: Elliotte Harold <elharo@metalab.unc.edu>
Date: Mon, 25 Oct 2004 04:45:59 -0400
Message-ID: <417CBD47.1020806@metalab.unc.edu>
To: www-xml-xinclude-comments@w3.org

It occurred to me there's another way to hide fatal errors besides 
unactivated fallbacks, also not yet covered by the test
suite. What happens if there's a fatal error hidden inside a non
XInclude child of an xi:include element?
For instance

<test xmlns:xinclude="http://www.w3.org/2001/XInclude">
   <xinclude:include href="utf8.xml" parse="text">
       Never processed
       <xinclude:include href="utf8.xml" parse="nonesuch">

Is this a fatal error or should it be ignored? (I can't imagine it's a 
resource error.) Are processors required or allowed to check inside 
elements that have no possibility of being processed?

The statement that "Other content (text, processing instructions, 
comments, elements not in the XInclude namespace, descendants of child 
elements) is not constrained by this specification and is ignored by the 
XInclude processor, that is, it has no effect on include processing, and 
does not appear in the [children] properties of the result infoset." 
This suggests that these are not fatal errors and that indeed a 
conforming processor must not so treat them.

I think this can be reconciled with the rest of the spec only if the 
statement "XInclude processors must stop processing when encountering 
errors other than resource errors" only if we claim that the processor 
does not "encounter" these errors because it skips this content. 
However, if that's the case then it seems logical that an XInclude 
processor never encounters a fallback if the xi:include element 
succeeds. so errors in any of its children will not be reported. 
Furthermore a problem with multiple fallback elements will only be 
encountered if the xi:include element fails.

Clarification from the spec would be very helpful.

Implementation note: not processing all descendants of an xi:include 
element for errors would preclude certain implementation strategies. For 
instance, you could not use DOM's getElementsByTagnameNS() or XPath to 
grab all the xi:include elements and check them for errors before 
proceeding because some of the errors might not count.

Elliotte Rusty Harold  elharo@metalab.unc.edu
XML in a Nutshell 3rd Edition Just Published!
Received on Monday, 25 October 2004 08:46:02 UTC

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