XML News from Monday, May 18, 2009

The W3C XML Schema Working Group has posted candidate recommendations of XML Schema 1.1 Part 1: Structures and XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes. According to the structures draft,

The major changes since version 1.0 include:

• Support for XML 1.1 has been added. It is now implementation defined whether datatypes dependent on definitions in [XML] and [Namespaces in XML] use the definitions as found in version 1.1 or version 1.0 of those specifications.
• A new primitive decimal type has been defined, which retains information about the precision of the value. This type is aligned with the floating-point decimal types which are included in [IEEE 754-2008].
• In order to align this specification with those being prepared by the XSL and XML Query Working Groups, a new datatype named anyAtomicType which serves as the base type definition for all primitive atomic datatypes has been introduced.
• The conceptual model of the date- and time-related types has been defined more formally.
• A more formal treatment of the fundamental facets of the primitive datatypes has been adopted.
• More formal definitions of the lexical space of most types have been provided, with detailed descriptions of the mappings from lexical representation to value and from value to ·canonical representation·.
• The validation rule Datatype Valid (§4.1.4) has been recast in more declarative form. A paraphrase of the constraint in procedural terms, which corrects some errors in the previous versions of this document, has been added as a note.
• The rules governing partial implementations of infinite datatypes have been clarified.
• Various changes have been made in order to align the relevant parts of this specification more closely with other relevant specifications, including especially the corresponding sections of [XSD 1.1 Part 1: Structures].

Changes since the previous public Working Draft include the following:

• To reduce confusion and avert a widespread misunderstanding, the normative references to various W3C specifications now state explicitly that while the reference describes the particular edition of a specification current at the time this specification is published, conforming implementations of this specification are not required to ignore later editions of the other specification but instead may support later editions, thus allowing users of this specification to benefit from corrections to other specifications on which this one depends.
• Schema Component Constraint enumeration facet value required for NOTATION (§3.3.20), which restricts the use of NOTATION to validate ·literals· without first enumerating a set of values, has been clarified.
• The use of the namespace whose URI is http://www.w3.org/2001/XMLSchema-datatypes continues to be defined. An earlier draft of this specification had introduced text deprecating that use; that text has been deleted. This change resolves issue 6522 Please un-deprecate the the namespace http://www.w3.org/2001/XMLSchema-datatypes, raised by John Cowan.
• The discussion of whitespace handling in whiteSpace (§4.3.6) makes clearer that when the value is collapse, ·literals· consisting solely of whitespace characters are reduced to the empty string; the earlier formulation has been misunderstood by some implementors.
• The value space of anyURI is now explicitly identified; this resolves issue 3264 xs:anyURI definition, raised by the W3C XML Query and XSL working groups.
• References to IEEE 754-1985 have been updated to refer to 754-2000 (resolves issue 6664).
• The description of the value space of precisionDecimal has been revised for better clarity; this resolves issue 3248.
• In the discussions of the built-in list datatypes, the display of facets which have a value for the datatype in question has been corrected; this resolves issue 6734 NMTOKENS IDREFS and ENTITIES should all have a "whiteSpace" facet. The wording used to introduce facets with values has also been revised to try to reduce confusion.
• The historical list of leap seconds given in earlier versions of this document has been removed (see issue 6554).
• The publication form of this document now includes a detailed prose description of the type hierarchy diagram in section Built-in Datatypes and Their Definitions (§3). We thank the W3C Web Accessibility Initiative's Protocols and Formats Working Group for their comments and assistance in this connection.
• Several other editorial corrections and improvements have been made.

In the datatypes spec,

The major revisions since the previous public working draft include the following:

• To reduce confusion and avert a widespread misunderstanding, the normative references to various W3C specifications now state explicitly that while the reference describes the particular edition of a specification current at the time this specification is published, conforming implementations of this specification are not required to ignore later editions of the other specification but instead may support later editions, thus allowing users of this specification to benefit from corrections to other specifications on which this one depends.
• The discussion of schemaLocation information in How schema definitions are located on the Web (§4.3.2) has been revised to try to make clearer the motivation for recommending user control over whether schema locations specified in the document instance should or should not be dereferenced. The new text describes some circumstances in which such schema locations typically should be dereferenced and some in which they should not, and attempts to set useful expectations for users and for implementors. These changes are intended to resolve issue 6655, raised by the W3C Web Accessibility Initiative's Protocols and Formats Working Group.
• The conceptual overview now included in Constraint Components (§2.2.4) some discussion of the overlap in functionality among identity constraints, conditional type assignment, and assertions, and identifies some of the factors which may be relevant in choosing among them; this change resolves issue 5023 Relationship between identity constraints and assertions.
• The discussion of schema import in Licensing References to Components Across Namespaces (§4.2.5.1) now states more clearly that references to components in external namespaces are an error if the namespace is not imported; this change addresses issue 5779 QName resolution and xs:import.
• The discussion of checking content-type restriction included in an appendix in earlier drafts of this specification has now been removed, as have some references to published algorithms for the problem. Several of the papers referred to are no longer publicly accessible on the Web, and the changes made to the Unique Particle Attribution (§3.8.6.4) have in any case rendered those algorithms obsolete. These changes resolve issue 6685 Appendix I Checking content-type restriction References Not Available.
• Discussions of global components now take <redefine> into account (addresses issue 5918 Top level declarations).
• The fact that ·xs:anyType· is its own base type has been clarified (addresses issue 6204 anyType/ur-Type: inconsistent whether it has a base-type).
• The rules for the "available collections" and "default collection" properties of the [XPath 2.0] dynamic context have been simplified; these properties are now required to be the empty set instead of being ·implementation-defined·. This improves interoperability and resolves issue 6540 Available documents in assertions.
• The [XPath 2.0] static context used for the evaluation of assertions has been clarified; it now explicitly includes the functions in the [Functions and Operators] fn namespace and constructors for all built-in types. This resolves issue 6541 Assertions and in-scope functions.
• The definition of ·context-determined type table· now explicitly excludes skip wildcards from consideration and makes clear that ·xs:anyType· never maps an element information item or an expanded name to any ·context-determined type table·. This aligns the treatment of type tables more closely with that of declared types and resolves issue 6561 Type Substitutable in Restriction.
• Several other editorial corrections and improvements have been made.

Comments are due by February 20.