- From: Paul Grosso <pgrosso@arbortext.com>
- Date: Mon, 4 Apr 2005 10:34:41 -0400
- To: <public-xml-core-wg@w3.org>
Here is an update for what I believe are the status/resolutions for the XInclude PEs. [Daniel, there are a several places where I indicate you need to update your PE document. If I don't say explicitly for a given PE, then the PE document is fine for that PE.] I've also included what appear to be necessary actions, but the actions should not go into the PE document. PEX1 Fatal XInclude errors in unactivated fallbacks --------------------------------------------------- We will add a paragraph to "Section 4.4 Fallback Behavior" about how there are no fatal errors relating to fallback-both errors within fallback elements and errors due to the wrong number of fallback elements-unless there is a resource error with the xinclude element surround this(these) fallback element(s). We will also add something after the third sentence of section 3.2 to this effect. ACTION to ???: Suggest actual wording. PEX2 URI or IRI errors handling ------------------------------- There will be no change to the spec. We don't expect implementors of XInclude to implement IRI processing, so whatever ends up happening with respect to IRIs isn't really the fault of the XInclude processor. However, we don't want to license such behavior, so we don't want to change our current wording here. ACTION to ???: Reply to the commentor. PEX3 What is an error --------------------- [Daniel, the PE document's resolution should be as follows.] The last bit of section 2 says: XInclude processors must stop processing when encountering errors other than resource errors, which must be handled as described in 4.4 Fallback Behavior. We will replace the above sentence with: XInclude processors must stop processing when encountering a fatal error. Resource errors must be handled as described in 4.4 Fallback Behavior. Also, at the end of the intro to 4.5, we will change "and does not produce an inclusion loop error" to "and does not produce an inclusion loop." As far as the case with an invalid value for the accept attribute, the definition of the accept attribute in section 3.1 does not make this an XInclude error of any kind, though it may cause an error in a lower level that might result in a resource error, for example. See also PEX7. [DV: end of new resolution text.] PEX5 XML encoding detection in parse="text" ------------------------------------------- Open. Read the email (it's hard to summarize): http://lists.w3.org/Archives/Public/www-xml-xinclude-comments/2004Dec/00 06 PEX6 parse="text" and Byte-Order Mark ------------------------------------- [Daniel, the PE document's resolution should be as follows.] We will add the following clarification that applies to all encodings: When the first character is interpreted as a BOM, it should be discarded. It is interpreted as a BOM in UTF-8, UTF-16, and UTF-32 encodings; it is not interpreted as a BOM in the UTF-16LE, UTF-16BE, UTF-32LE, and UTF-32BE encodings. [DV: end of new resolution text.] PEX7 Illegal value in encoding attribute ---------------------------------------- [Daniel, the PE document's resolution should be as follows (which is very similar to what you have, but with slightly different wording).] See also PEX2 and PEX3. We will change the wording for the encoding attribute in section 3.1 to change the sentence "The value of this attribute is an EncName as defined in XML specification, section 4.3.3, rule [81]." to say something like "The value of this attribute SHOULD be a valid encoding name." So an invalid encoding attribute isn't a fatal xinclude error, though it might cause a resource error at some point. [DV: end of new resolution text.] PEX11 Reference to RFC 2279 should be RFC 3629 ---------------------------------------------- [Daniel, the PE document's resolution should be as follows (which is basically what you have, but with the "extra" discussion omitted).] We will update the reference from 2279 to 3629. [DV: end of new resolution text.] PEX14 What if encoding is not an EncName? ------------------------------------------- Francois suggests making it a fatal xinclude error if the XInclude processor actually goes to try to use an encoding value and that value doesn't conform to the syntax of EncName. What do others think? PEX15 XPointers with percent escapes: what type of error? ----------------------------------------------------------- Open. Read the email (it's hard to summarize): http://lists.w3.org/Archives/Public/www-xml-xinclude-comments/2004Oct/00 08
Received on Monday, 4 April 2005 14:35:57 UTC