This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Rule 1 says "then the appropriate case among the following is true". However, if the element has element-only content, then both 1.3 and 1.4 must be satisfied. This rule also includes the note "Note: It is ·implementation-defined· whether a schema processor supports the definition of white space from [XML 1.1], or that from [XML 1.0], or both." However, the definition of "white space" (which should really be one word, as "white" is not used adjectivally...) is the same in XML 1.0 and XML 1.1.
On the first point, see also bug 4368. On the second point, you are right. And yet -- is it a fool's errand to wish to make explicit that where the treatment of whitespace (or white space) differs between XML 1.0 and 1.1 (I mean in particular the treatment of U+0085, the NEL of ISO 6429) the schema processor may do either, and should document which? The wording quoted talks about white space, not about the 's' production in the XML spec; I have a vague recollection of wording it carefully to ensure that it made sense even though the 's' production has not change. Of course XSDL defines its input (for better or worse) as an infoset, not an XML document, and so one could argue that the difference is really utterly out of scope for the spec. In that case, I think I would probably argue for a non-normative Note pointing out the issue in terms that make clear that it's (a) a question of how the input infoset is created, and thus out of scope for the XSDL spec, and (b) a question of how an XML document taken as input is read, and thus of some interest for users who hope to use our technology instead of only admiring the purity of our spec's concentration on untestable abstractions, and who care about getting the same results from one processor to another.
Your reply confuses me. Our text refers to "the definition of white space" in [XML 1.0]/[XML 1.1]. If that reference is to the text: S (white space) consists of one or more space (#x20) characters, carriage returns, line feeds, or tabs. White Space [3] S ::= (#x20 | #x9 | #xD | #xA)+ then the definition is the same in both versions of the XML spec, so the distinction we are making is spurious. If the reference is to some other definition of white space, then we need to make it clear what we are actually referring to. The context: "E has no character information item [children] other than those whose [character code] is defined as a white space in [XML 1.1]." suggests that we are looking for a list of Unicode characters classified as white space, and the S production is the only such list I can find. XML 1.1 refers to x85 and x2028 as "line-end" characters, it never refers to them as "white space" characters.
WG instructs the editors: 1) first problem, change to "all must be true" 2) second problem, remove the note.
In an effort to make better use of Bugzilla, we are going to use the 'severity' field to classify issues by perceived difficulty. This bug is getting severity=minor to reflect the existing whiteboard note 'easy'.
A wording proposal for this issue (among others) was sent to the XML Schema WG on 4 February 2008. http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.consent.200802.html (member-only link) For some issues, the proposal is effectively to make no change; see the Status section of the proposal for the specifics.
During its telcon today, the XML Schema WG accepted the 'Structures Omnibus 2' proposal, which includes changes intended to resolve this issue. (Or, for some issues, contains the editors' proposal that the issue should be closed without further changes.) http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.consent.200801.html (member-only link) Accordingly, I'm marking the issue resolved. The originator of this issue (or in some cases the individual, acting on behalf of a group, who filed the comment) should receive an email notification of this change. Please examine the changes and let us know if you agree with this resolution of your issue, by adding a comment to the issue record and changing the Status of the issue to Closed. Or, if you do not agree with this resolution, please add a comment explaining why. If you wish to appeal the WG's decision to the Director, then also change the Status of the record to Reopened. If you wish to record your dissent, but do not wish to appeal the decision to the Director, then change the Status of the record to Closed. If we do not hear from you in the next two weeks, we will assume you agree with the WG decision.