This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This bugzilla entry is opened as a temporary place to capture a list of known incompatibilities between Schema 1.0 and 1.1 (affecting Part 2), with a view to eventual publication as a non-normative Appendix. The aim here is only to describe cases where the behaviour in 1.0 was clear, and has clearly changed. There are many additional cases where the 1.0 behaviour was unclear, in which case incompatibilities may arise in a specific product depending on how it interpreted the 1.0 specification. 1. xs:duration values that were distinct in 1.0 are considered identical in 1.1 if they are different representations of the same period of time (for example P1Y = P12M). This means, for example, that given a type derived from xs:duration with an enumeration facet permitting the value "P1Y", the value "P12M" was invalid in 1.0 but becomes valid in 1.1. This also affects fixed values and identity constraints affecting xs:duration values. 2. The interpretation of dates with negative year numbers has changed. Year zero was invalid under 1.0, but becomes valid in 1.1. The years in which February 29 is a valid date were -0004, -0008 etc in 1.0, and are -0003, -0007, etc in 1.1. This change causes some documents that were valid under 1.0 to become invalid under 1.1, and vice versa. 3. XML Schema 1.1 allows (but does not require) processors to use the XML 1.1 definitions of NCName and related types, which allow use of some characters that were not permitted in XML 1.0. An XML Schema 1.1 processor that takes this option will label some names as valid that were invalid in 1.0. This change also affects the meaning of the metacharacters \i and \c in regular expressions. In rare circumstances the change to the meaning of \i and \c may cause documents that were valid under 1.0 to become invalid under 1.1. 4. XML Schema 1.0 did not precisely spell out which sequences of characters were valid as xs:anyURI values, but referred indirectly to the RFCs in which URIs are defined. XML Schema 1.1 states that any sequence of characters is valid as an xs:anyURI value. Thus some documents that were invalid in 1.0 become valid in 1.1. 5. XML Schema 1.0 specified that implementations must support 18 digits for integer and decimal data types; this requirement has been relaxed to 16 digits in 1.1. Schemas and instance documents that make use of more than 16 digits are therefore no longer guaranteed to be interoperable across all processors. 6. A new type xs:anyAtomicType has been introduced as the base type for all primitive atomic types. This does not affect the validity of any schema documents or instance documents, but it may affect applications that make programmatic access to schema components or to the PSVI. 7. In any case where the set of valid values of a data type has changed (see other entries in this list), the use of that data type as a member of a union may cause the type assigned to a particular lexical form to change to a different member type of the union type.
Schema 1.1 processors MUST provide the built in precisionDecimal type, and Schema 1.0 processors MUST not build in a primitive type of that name. (Did I miss this in your original list Michael? I saw you caught anyAtomic.) Noah
No, I didn't say anything about precisionDecimal. Is there an incompatibility? I don't think we need to mention that a 1.0 schema document is in error if it uses precisionDecimal and a 1.1 schema document isn't, because that's true of every new feature we add. I guess there's an impact on generic applications that ask what type something is, they need to cater for this new possible answer. Is there any other way in which adding precisionDecimal can break anything?
Michael Kay wrote: > Is there an incompatibility? I don't think > we need to mention that a 1.0 schema document > is in error if it uses precisionDecimal > and a 1.1 schema document isn't, because > that's true of every new feature we add. Indeed, and I assumed that to be the sort of incompatibility we would want to list. I can see it either way. If you're just worrying about breaking backwards compatibility, then this stuff need not be listed. If you're worried about both forward and backwards compatibility, then indeed the new features would need to be listed. So, in structures, we'd need to say that (A?, any) is now legal, where before it wasn't. Is it clear that what was wanted was only a list of backwards-incompatibilities? If so, I'm not sure the XML 1.1 names belong there. Perhaps I'm not thinking clearly, but I thought that the only backwards incompatibilities were at the Infoset level. In other words, I thought that every legal XML 1.0 character was a legal XML 1.1 character. At the very least, I think that whatever list we supply should be introduced with an explanation of what sorts of incompatibilities it includes, and which ones it doesn't. Thanks. Noah
I think that an invalid schema document becoming valid in the next release is a change that everyone expects and no-one worries about: that's the way languages move forward, and it belongs in our "list of changes since 1.0" rather than our list of incompatibilities. But I think that an invalid instance document becoming valid in the next release is worthy of comment, because it allows documents through the filter that the receiving application might not be able to cope with, and might be trying to protect itself against; it also means that a sender who is validating outgoing documents using Schema 1.1 might be transmitting stuff to a recipient who will validate it with Schema 1.0 and find it to be invalid.
Michael Kay offered, and the WG accepted, the following categories: 1) Schema doc was valid in 1.0 and invalid in 1.1; 2) Cases where the validity of an instance document will change, in either direction, even if the schema hasn't changed 3) 'Validity' hasn't changed, but the PSVI has changed in some other way (Straight-up additions aren't news, but actual changes for previously supplied values are). 4) Changes to the schema component model (e.g. elements can be in more than one substitution group).
The WG decided not to add this material to the spec itself, but to create a wiki entry where the material could be developed extraneously to the spec.
(In reply to comment #6) > The WG decided not to add this material to the spec itself, but to create a > wiki entry where the material could be developed extraneously to the spec. Therefore I'm marking this WONTFIX (as far as the spec itself is concerned). Since MK originated the bug, entered the WG response, and has not further commented, I will also mark it CLOSED.