Issue qt-2004Feb0386-01 [XPath] Consistency Constraints

Martin,

In their face to face meeting today, the XML Query and XSL Working
Groups discussed your comment of 15 February "[XPath] Consistency
Constraints" on the 2003 last call draft of XPath 2.0.

http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0386.html

This is tracked in our issue system as issue qt-2004Feb0386-01
http://www.w3.org/XML/Group/xsl-query-specs/last-call-comments/xpath20/issues.html#qt-2004Feb0386-01

Thank you for your comment.

You wrote:

    2.2.5 says: "Enforcement of these consistency Constraints is
    beyond the scope of this specification."

    Who/what enforces these constraints? In case they are not
    enforced, what are they there for?

The constraints are pre-suppositions for the correct functioning of
systems which implement XPath 2.0.  They are not necessarily
enforceable by software, and (as the sentence you quote indicates)
XPath processors are not required to enforce them. They form, in
effect, part of the contract between an XPath implementation and the
user or agent which calls upon it to do some particular bit of work,
and they must be enforced by the user or the environment within which
XPath is used, in order for XPath expressions to have defined values.

An example may make this clear.

Let us suppose that I validate a document against a particular schema,
producing a post-schema-validation infoset, which I pass to an XPath
implementation.  I invoke the XPath processor, however, in such a way
as to ensure that the only schema information it can have access to is
inconsistent with the schema I used to produce the PSVI.  Can I
reasonably expect the XPath implementation to produce correct results
under these circumstances?  What measure can one use to determine
correctness?

In the interests of layering and modularization, we have chosen not to
require that XPath processors must themselves incorporate an XML
Schema processor and themselves perform schema-validity assessment.
As a consequence of this decision, the XPath processor cannot, in the
general case, have any knowledge of whether its schema information is
consistent with the schema used to validate the XPath input.  

Since responsibility for ensuring the truth of the consistency
constraints listed in section 2.2.5 cannot be borne by the XPath
implementation, it must be borne by the invoker.  In the example, my
way of invoking the XPath processor failed to provide the required
conditions, and thus I have no reason to complain if the processor
fails to produce the results I expect.

In the interests of making clearer the role of these consistency
constraints, answering your question, and resolving your comment, we
have changed the relevant text of the specification.  The paragraph
you commented on read in its entirety

    In order for XPath to be well defined, the data model, the static
    context, and the dynamic context must be mutually consistent. The
    consistency constraints listed below are prerequisites for correct
    functioning of an XPath implementation. Enforcement of these
    consistency constraints is beyond the scope of this specification.

To this, the current draft of the specification adds the following
sentence:

    This specification does not define the result of an expression
    under any condition in which one or more of these constraints is
    not satisfied.

It may be read in context at

    http://www.w3.org/TR/xpath20/#id-consistency-constraints

Please let us know whether this change addresses your question to your
satisfaction.  If we do not hear from you in the next few weeks we
will assume you are content with the change and do not wish any
further consideration of this issue.

best regards,

-C. M. Sperberg-McQueen
 for the XSL and XML Query Working Groups