public comments from the XSL WG on the Query Data Model

The XSL WG has reviewed the XML Query Data Model document (dated 11
May 2000) and has following comments and proposal.



Specific Issues with the current document:
-----------------------------------------

(1) Overall, the way that the XML Query Data Model handles node types
    is somewhat awkward from an XPath perspective:

    - some functions are defined on the Node type and some on specific
      types of Node; for example, isDocNode is defined on Node, but
      children is defined separately for each kind of node

    - it uses union types rather than more familiar subtyping

    - relationship of the isXXXNode functions to the type system is
      unclear

    - it uses many different separate isXXXNode functions with an
      implicit constraint that only one of them returns true for a
      given node, rather than a single nodeType function (as in the
      DOM)

(2) The approach taken to data-typing by the XML Query Model appears
    to have difficulty dealing with the possibility that the string
    representation of a value of particular data-type in an element
    can be interrupted by processing instructions and comments; for
    example, the integer 10 might be represented by

      <amount>1<?bizarre processing instruction?>0</amount>

(3) Given that the infoset does not define node identity, we feel
    that the XML Query data model must define node identity
    rigourously.  It appears that while the current document assumes
    such identity, it does not formally define it.

(4) The data model has the concept of constructors to describe the
    data model of result trees. In the current model, nodes have
    accessors for parents, however, parents are not specified in
    constructors. This appears to be a problem.

(5) We believe that the approach of representing complex schema types
    by the data model of that type's schema as an XML document is
    rather inadequate. This places the burden of processing the
    schema (traversing import/include links, detecting inheritance,
    equivalence classes etc.) on every user. We would prefer an
    approach where element types are represented by some processed
    form of the schema defining the type.

(6) We also noticed the following relatively minor issues:

    - It would be preferable if the the XML Query Data Model used terms
      and abbreviations consistent with XPath. For example, it should
      use "ProcessingInstructionNode" not "PINode". The choices in
      XPath were made conciously to maximize useability and we urge
      the query group to build on the XPath experiences.

    - It is not clear to us why the name of an ElemNode is a
      *reference* to a QNameValue and not just a QNameValue.

    - It appears that InfoItemNode is not fully specified. Which info
      items it represents is not clear and the possible answers all
      have drawbacks: If all implementations are required to support
      all info items, then that imposes a significant implementation
      burden, with very little benefit for most users. If not all are
      required, then there is a significant potential interoperability
      problem.



Discussion Points:
-----------------

(1) Given that the XPath data model is already present, we feel
    strongly that the XML Query data model should be built with
    an appropriate relationship to the XPath data model. 

(2) The above approach makes sense if and only if the XML query group
    decides to use XPath as a part of the query language. In that
    case (i.e., if there is committement to use XPath), we feel
    very strongly that the data models must be closely related.

(3) XPath clearly does not support typed values at this time. Adding
    schema support to XPath is a vital work-item from the XPath 2.0
    effort. Adding types to the XPath data model could be achieved by,
    for example, adding a "type" node for each element node and
    attribute node; the "type" node could be accessible by a new
    "type" axis in XPath; and a new typed-value() function could
    return the value of a element or attribute converted to the type
    specified by its type node.

(4) It is not clear to us that the semi-formal approach used in 
    defining the query data model is sufficiently rigourous. It is
    clear that the notation leads to a more compact specification,
    but it is not obvious whether resulting specification is more
    rigourous than a prose specification.

Received on Thursday, 20 July 2000 07:17:45 UTC