XInclude PE status/resolutions

Here are what I believe are the status/resolutions
for the XInclude PEs.

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
---------------------
[We have a partial resolution with one part still open.]

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.  However,
we did not come to a find resolution here.

See also PEX7.

ACTION to Paul:  Send email about this open issue: 
invalid values for the accept attribute.


PEX4 The encoding attr should trigger Accept-Charset
----------------------------------------------------
This comment is made obsolete by the fact that we have 
removed accept-charset from the final Rec.


PEX5 XML encoding detection in parse="text"
-------------------------------------------
Open.

ACTION to Paul:  Send email about this open issue: 
XML encoding detection in parse="text".


PEX6 parse="text" and Byte-Order Mark
-------------------------------------
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 *{LE,BE} encodings.

[We should expand "*{LE,BE}" in the above.  What
is its correct expansion?]


PEX7 Illegal value in encoding attribute
----------------------------------------
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.


PEX8 encoding attribute priority
--------------------------------
This comment was against the PR draft. We believe we've 
now made this clear in section 4.3 of the Rec.


PEX9 encoding attribute content
-------------------------------
Same issue/resolution as PEX7.


PEX10 accept-* attributes improperly defined
--------------------------------------------
We will change:

 Values containing characters outside the range
 #x20 through #x7E are disallowed in HTTP headers,
 and must be flagged as fatal errors.

to be worded as follows:

 Values containing characters outside the range
 #x20 through #x7E must be flagged as fatal errors.


PEX11 Reference to RFC 2279 should be RFC 3629
----------------------------------------------
We will update the reference from 2279 to 3629.


PEX12 getElementById
--------------------
We sympathize. Unfortunately, we can't change the DOM, 
but at least some of these problems are said to be 
fixed in DOM Level 3.


PEX13 Normalize newlines when parse="text"?
-------------------------------------------
When processing an xi:include element with parse="text", 
there is no newline normalization.


PEX14 What if encoding is not an EncName?
-------------------------------------------
Open.

ACTION to Paul:  Send email about this open issue: 
What if encoding is not an EncName?


PEX15 XPointers with percent escapes: what type of error?
-----------------------------------------------------------
Open.

ACTION to Paul:  Send email about this open issue: 
XPointers with percent escapes: what type of error?

Received on Wednesday, 23 March 2005 17:09:04 UTC