W3C home > Mailing lists > Public > public-qt-comments@w3.org > August 2003

XML Schema WG comments on Data Model

From: C. M. Sperberg-McQueen <cmsmcq@acm.org>
Date: Fri, 01 Aug 2003 13:45:10 -0600
Message-Id: <>
To: public-qt-comments@w3.org
Cc: W3C XML Schema IG <w3c-xml-schema-ig@w3.org>

Dear colleagues:

The XML Schema Working Group congratulates the XML Query and XSL
Working Groups on their progress, and in particular on the Last Call
draft of "XQuery 1.0 and XPath 2.0 Data Model".

We have now reviewed the last call draft, and our comments are at
(an ASCII version is reproduced below for the convenience of those
with access to their email but not to the Web).

We apologize for the tardy arrival of these notes.

-C. M. Sperberg-McQueen, for the W3C XML Schema WG

W3C XML Schema WG

Notes on XQuery 1.0 and XPath 2.0 Data Model

1 August 2003

      * 1. [7]Schema-related issues
           + 1.1. [8]The term type
           + 1.2. [9]Derivation of simple types
           + 1.3. [10]Items and singleton sequences
           + 1.4. [11]The implications of [validity] != valid
           + 1.5. [12]Anonymous local types
           + 1.6. [13]Target namespaces
           + 1.7. [14]Lexical spaces, reference, containment
      * 2. [15]Other technical issues
           + 2.1. [16]Atomic values and singleton sequences
           + 2.2. [17]Node identity
           + 2.3. [18]Names in namespace nodes
           + 2.4. [19]Elements labeled xs:anyType in the PSVI
           + 2.5. [20]Minor items
                o 2.5.1. [21]Infoset-only processing
                o 2.5.2. [22]Prefix property
                o 2.5.3. [23]Sequences in sequences
                o 2.5.4. [24]Synthetic data models
      * 3. [25]Editorial notes
           + 3.1. [26]Comments reviewed by the Working Group
           + 3.2. [27]Comments not reviewed by the Working Group

    This document contains comments on the Last Call draft of 2 May 2003
    of [28]XQuery 1.0 and XPath 2.0 Data Model (hereinafter DM) from the
    XML Schema Working Group. These comments were prepared by an ad hoc
    Task Force and most of them were reviewed and revised by the XML
    Schema Working Group at its teleconference of 1 August 2003. The
    editorial comments included in [29]section 3.2 were not reviewed by
    the XML Schema Working Group.
    In addition to the comments below, please note that several of the
    [30]general comments sent on 14 July relate to the data model
    specification. Some of those comments sent earlier overlap with some
    comments below.

1. Schema-related issues

    The comments in this section relate to the use of XML Schema in the
    F/O specification and thus to the particular area of responsibility
    borne by the XML Schema WG.

1.1. The term type

    DM appears to use the term type for several related but different
    concepts; we believe it would be desirable if you were to clarify the
    meaning of the term, or at least if you called the reader's attention
    to its overloading.
    The Data Model specification appeals to the Formal Semantics
    specification, which says types are XML Schema types. However, XML
    Schema tries to avoid the term "type", instead using "type
    Among the uses of "type" we have noticed are:
     1. T1. a name (for example, as used by the dm:type accessor).
     2. T2. a set of values (this sense is used by XML Schema's internal
        work on a formalization, which includes a "Type Lattice").
     3. T3. an XML Schema Type Definition component (simple or complex).
        Defines a set of values and certain properties, such as [name],
        [baseType], etc.
     4. T4. an OO class. Defines a set of values, inheritance info, and

    Specifically, we suggest that the dm:type accessor be renamed to
    dm:type-name and that "type" be explicitly defined. If "type" is just
    a synonym for "type definition", say so in the definition ot "type".

1.2. Derivation of simple types

    Section 5 Atomic Values reads in part:

      An XML Schema simple type [XMLSchema Part 2] may be primitive or
      derived by restriction, list, or union.

    We think it will help avoid confusion among users, implementors, and
    (not least) discussion among Working Groups if you use XML Schema
    terminology here. Perhaps:

      An XML Schema simple type definition [XMLSchema Part 2] has a
      [variety], which may be atomic, list or union. If [variety] is
      atomic, the type definition may be primitive or derived by

    The XML Schema WG wishes to de-emphasize the use of the term "derived
    by" in XML Schema Part 2 in describing union and list contruction. The
    term "derived by" is used only colloquially there and is unfortunately
    confused with derivation in the proper sense (i.e. restriction and
    extension). All non-primitive simple types are derived by restriction.
    List types may be restrictions of xs:anySimpleType or other lists.
    Similarly for union types. Please don't propagate the confusion we
    [We are aware that it would be useful to have a simple term other than
    derivation to describe the relation between a list type and its item
    type, or that between a union type and its member types; we need it as
    much as you do. Suggestions are welcome.]

1.3. Items and singleton sequences

    Section 6 Sequences reads in part:

      An important characteristic of the data model is that there is no
      distinction between an item (a node or an atomic value) and a
      singleton sequence containing that item.

    One consequence of this characteristic is that the types xs:integer
    and a list of xs:integer with length constrained to 1 have exactly the
    same value space in the Data Model. That is, each value in the value
    space is a sequence of a single xs:integer. This is different from the
    XML Schema value spaces for the two types. Might this cause a problem
    for functions or other uses of the Data Model?
    We believe further discussion is needed here.

1.4. The implications of [validity] != valid

    Section 3.6 para 2 reads in part: "The only information that can be
    inferred from an invalid or not known validity value is that the
    information item is well-formed."
    This is not true in the general case: the values of the properties
    [validity] and [validation attempted] interact, so that some
    inferences beyond well-formedness can be made. (If [validity] is
    'notKnown', for example, we can infer without examining the PSVI that
    [validation attempted] is not 'full'. If for some node N [validity] is
    'invalid', we can infer that declarations are available for at least
    some element or attribute information items in the subtree rooted in
    N.) The data model doesn't have to be interested in those inferences,
    but it is simply incorrect to say that they don't exist.
    On the whole, we believe that that the data model misses an
    opportunity by failing to exploit the information contained in the
    [validity] and [validation attempted] properties more fully.

1.5. Anonymous local types

    Section 3.6 has an extended list of cases describing how the namespace
    and local name of a type are found. This list reads in part:

      * If the [validity] property exists and is `valid':
           + ...
           + If the [type definition] property exists and its {name}
             property is present:
                o the {target namespace} and {name} properties of the
                  [type definition] property.
           + ...
           + If [type definition anonymous] exists:
                o If it is false: the [type definition namespace] and the
                  [type definition name]
                o Otherwise, the namespace and local name of the
                  appropriate anonymous type name.

    The above structure does not handle the case of an anonymous type when
    the schema processor provides the [type definition] property instead
    of the [type definition name] property and its fellows.
    We think the [type definition] rule can readily be rephrased so that
    the result is parallel to the case when the upstream schema processor
    provides [type defintion name] instead of [type definition]:

      * If the [validity] property exists and is `valid':
           + ...
           + If the [type definition] property exists[DEL: and its {name}
             property is present :DEL] :
                o [INS: If the [type definition]'s {name} property exists:
                  :INS] the {target namespace} and {name} properties of
                  the [type definition] property.
                o [INS: Otherwise, the namespace and local name of the
                  appropriate anonymous type name. :INS]
           + ...

1.6. Target namespaces

    Section 3.4 Types reads in part:

      Since named types in XML Schema are global, an expanded-QName
      uniquely identifies such a type. The namespace name of the
      expanded-QName is the target namespace of the schema and its local
      name is the name of the type.

    A schema does not have a target namespace; a schema document has a
    target namespace.
    One possible repair would be:

      Since named types in XML Schema are global, an expanded-QName
      uniquely identifies such a type. The namespace name of the
      expanded-QName is the {target namespace} property of the type
      definition, and its local name is the {name} property of the type

    Another might be:

      Since named types in XML Schema are global, an expanded-QName
      uniquely identifies such a type within a schema.

    We believe this to be relatively important.

1.7. Lexical spaces, reference, containment

    Section 2 refers to: "the lexical space referring to constructs of the
    form prefix:local-name". Perhaps substitute "the lexical space
    containing ..." Lexical forms may, with a certain investment of time
    and energy, be thought of as `referring to' values, but the lexical
    space as a whole does not refer. The lexical space of QName does
    contain, even if it does not refer to, constructs of the form

2. Other technical issues

    The comments in this section relate to technical issues other than the
    use of XML Schema in the F/O specification; the XML Schema WG claims
    no particular responsibility or expertise on these questions but
    raises them because they seem to need attention.

2.1. Atomic values and singleton sequences

    In section 2 Notation, after indicating how to represent Node and Item
    in the syntax, DM says "Some accessors can accept or return
    This may need clarification; elsewhere we had been led to think that
    everything is a sequence. Please emphasize that Node, Item, and atomic
    values in the syntax correspond to singleton sequences, and that some
    accessors accept less-constrained sequences.
    Some members of the XML Schema WG add that DM seems to conflate the
    notations of list and sequence, which are distinct and should not be

2.2. Node identity

    Sections 3.1 and 3.2 raise the question of node identity and stable
    Does a node maintain its identity on being modified? on being added to
    another tree? If so, wouldn't its ordering change?

2.3. Names in namespace nodes

    Section 4.3 Elements lists, among the constraints that element nodes
    must satisfy:
    7. The namespace nodes of an element must have distinct names.
    This requirement contradicts the definition of dm:name for namespace
    nodes, for processors that choose not to preserve prefix information.
    All their namespace nodes will name [or have] the same name, namely
    the empty sequence.

2.4. Elements labeled xs:anyType in the PSVI

    Section 4.3.2 says in part:

      If the element node's type is xs:anyType, the dm:typed-value
      accessor returns the node's string value as xs:anySimpleType.

    This seems to contradict section 4.1.6:

      If the node is an element node with type xs:anyType, then its typed
      value is equal to its string value, as an instance of

2.5. Minor items

2.5.1. Infoset-only processing

    Section 3.6 says, under the heading "Infoset-only processing":

      Note that this processing is only performed if no part of the
      subtree that contains the node was schema validated. In particular,
      Infoset-only processing does not apply to subtrees that are "skip"
      validated in a document.

    Which subtree is "the" subtree? A given node is contained by many
    subtrees. Perhaps read "if no part of any subtree containing the node
    was schema validated"?

2.5.2. Prefix property

    Section 4.3.4 says:

      An implementation must construct the value of the [prefix] property
      as if the following algorithm was applied: if the element has at
      least one namespace node whose namespace URI is the same as the
      namespace name of the xs:QName returned by the dm: node-name
      accessor ...

    Please be clear about the meaning of "namespace URI" or the namespace
    node. Is it the [uri] property of the namespace node or the namespace
    uri part of the node-name property of the namespace node?

2.5.3. Sequences in sequences

    Section 2 reads in part:

      In a sequence, V may be a Node or AtomicValue, or the union
      (choice) of several categories of Items.

    It's not immediately clear to all readers what this means. It appears
    a first glance to say that if V*, V?, or V+ appear in (the description
    of) a sequence, then V may be or denote a Node or an AtomicValue or a
    union. But if sequences cannot appear in sequences, and V* and V? and
    V+ all denote sequences (as specified in the list immediately above),
    then if V*, V?, or V+ appear in (the description of) a sequence S,
    then sequence S would appear to violate the rule that sequences cannot
    contain other sequences. (Unless "In a sequence" means `When appearing
    as the description of a sequence'.)

2.5.4. Synthetic data models

    Section 3.3, para 2 reads:

      Although we describe construction of a data model in terms of
      infoset properties, an infoset is not an absolutely necessary
      precondition for building an instance of the Data Model. Purely
      synthetic data model instances are entirely appropriate as long as
      they obey all of the constraints described in this document.

    We agree that it is worthwhile to point out that synthetic instances
    of the Data Model are possible, and need not derive from some
    pre-existing XML document or information set. Some members of the XML
    Schema WG believe, however, that the formulation just quoted does not
    do full justice to the abstract nature of the infoset as a concept.
    Any process which can create an instance of the Data Model clearly has
    access to the set of information defined by the Infoset Rec and can
    thus be thought to have, or be, an infoset itself. To this line of
    thinking, the construction of a synthetic Data Model is itself a
    sufficient demonstration that the necessary information, and thus the
    necessary infoset, is available.
    Two possible fixes may be worth suggesting:

      Although we describe construction of a data model in terms of
      infoset properties, a [INS: pre-existing :INS] infoset is not an
      absolutely necessary precondition for building an instance of the
      Data Model. Purely synthetic data model instances are entirely
      appropriate as long as they obey all of the constraints described
      in this document.


      Although we describe construction of a data model in terms of XML
      infoset properties, a [INS: pre-existing XML document :INS] is not
      an absolutely necessary precondition for building an instance of
      the Data Model. Purely synthetic data model instances are entirely
      appropriate as long as they obey all of the constraints described
      in this document.

3. Editorial notes

    In the course of our work, some editorial points were noted; we list
    them here for the use of the editors. We do not particularly expect
    formal responses on these comments.

3.1. Comments reviewed by the Working Group

     1. QNames. Section 2 Notation reads in part:

      [Definition: An expanded-QName is a pair of values consisting of a
      namespace URI and a local name. They belong to the value space of
      the XML Schema type xs:QName. When this document refers to xs:QName
      we always mean the value space, i.e. a namespace URI, local name
      pair (and not the lexical space referring to constructs of the form
        Thank you for being specific about value-space vs. lexical space.
        Please also be specific on whether the namespace URI can be absent
        or not.
     2. Section 3.3: The definition

      [Definition: A Post Schema Validation Infoset, or PSVI, is the
      augmented infoset produced by an XML Schema validation episode.].
        has an extra full stop at the end.
     3. Section 3.4 para 6:

      It returns xs:anyType or xs:anySimpleType if no type information
      exists, or if it failed W3C XML Schema validity assessment.
        Are "xs:anyType" and "xs:anySimpleType" expanded-QNames? They
        don't look like it.
     4. Section 4.1.1: We suggest using "[base-uri]" rather than
        "base-uri" when referring to the infoset propery, to avoid
        confusion with the base-uri accessor. In general, we believe all
        references to infoset properties should use the brackets.
     5. Section 4.1.3:

      dm:node-name returns the qualified name of the element or
        The XML Infoset does not define a [qualified name] for items. For
        "qualified name" perhaps read "expanded QName".
     6. Section 4.1.6, bulleted list: Two of the bullets begin "If the
        item is" and the rest begin "If the node is". Why are these
        different? At first we thought the difference reflected a crucial
        difference in the tests being performed, but the entire list is
        about nodes; there are no items under discussion which are not
     7. Section 4.3.2, repeated in 4.4.2: the first bullet item says that
        under certain circumstances the result will be an "atomic value
        3.14 of type decimal". Should that be "xs:decimal"?

3.2. Comments not reviewed by the Working Group

    When the XML Schema Working Group reviewed the draft comments provided
    by our task force, we focused on substantive comments; the following
    editorial comments were not reviewed owing to lack of time. They are
    transmitted on behalf of the Working Group, but they do not
    necessarily carry the consensus of the Working Group.
     1. Section 3.3 para -1: "inconsistent data models are forbidden".
        There has not thus far been any definition of consistency for data
        models; if it's provided elsewhere, a forward reference might be
        in order. If it's not provided elsewhere, it needs to be.
     2. abstract. For "the data model of at least XPath 2.0 ... and any
        other specifications that reference it" perhaps read "the data
        model of XPath 2.0 ... and of any other specifications that
        reference it".
     3. Section 1 Introduction para 2: "... it defines precisely the
        information contained in the input to an XSLT or XQuery
        Surely it specifies a minimum, by defining the information which
        must be contained, rather than specifying both a minimum and a
        maximum by forbidding any input to contain any other information.
        If one has concealed a coded message in a document by varying the
        amount of white space before the '>' characters which close the
        tags in an XML document, that coded message is certainly (a)
        information, and (b) present in the input to the processor and (c)
        not defined by this Data Model.
        It may make sense to say that this document defines precisely
        which information present in the input it is that is relevant to
        XSLT or XQuery processors (although formulating this without
        falling into traps is also fraught with difficulty), but it seems
        simply wrong to deny that information other than what is defined
        here is present in the input.
     4. Section 2 Notation. Since this is to be a free-standing document,
        a short description of what the sample signature means would be
        useful. As it is, the combination of (a) the sample, clearly
        intended to help the reader understand the notation, with (b) the
        absence of any explication, manages to do a rather effective job
        of sapping the reader's will to continue reading.
     5. Section 3.3 para -1. "Validation is described conceptually as a
        process of ..." -- either insert a pointer to the section or
        document which provides this description or (if this is the
        description) read "Validation is a process of ..."
     6. Section 3.4 para 2. For "For named types, which includes ..." read
        "For named types, which include ..." (subject-verb agreement)
     7. section 3.4 para 6. "The data model defines ... It returns ... if
        it ..." The noun phrase "data model" is almost certainly not
        intended as the antecedent of either of the two occurrences of it,
        but syntactically it has a better claim than any other noun phrase
        around. For the first, perhaps read "The accessor"; for the
        second, perhaps "the node" or "the argument".
     8. section 3.4 para -1. For "The semantics of such operations, e.g.
        checking if a particular instance of an element node has a given
        type is defined in [Formal semantics]" read "... if a particular
        instance ... has a given type, is defined in ...".


    1. http://www.w3.org/
    2. http://www.w3.org/Architecture/
    3. http://www.w3.org/XML/Group
    4. http://www.w3.org/XML/Group/Schemas
    5. http://www.w3.org/Member/Eventscal.html
    6. http://www.w3.org/Member/#confidential
   28. http://www.w3.org/TR/xpath-datamodel/
   29. http://www.w3.org/XML/Group/2003/08/xmlschema-datamodel-comments.html
   30. http://www.w3.org/XML/Group/2003/07/xmlschema-query-notes.html
Received on Friday, 1 August 2003 15:46:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:56:49 UTC