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

Re: [Fwd: Re: [XPath] Consistency Constraints]

From: Martin Duerst <duerst@w3.org>
Date: Tue, 17 Aug 2004 16:45:53 +0900
Message-Id: <4.2.0.58.J.20040817163501.02030ab8@localhost>
To: Jonathan Robie <jonathan.robie@datadirect.com>
Cc: Paul Cotton <pcotton@microsoft.com>, public-qt-comments@w3.org

At 09:50 04/08/16 -0400, Jonathan Robie wrote:
>Martin Duerst wrote:
>
>>If an implementation must ensure that the constraints are met, then
>>I don't understand why the spec then goes on to say "Enforcement of
>>these consistency constraints is beyond the scope of this specification."
>>I think it should rather say something like "If the constraints are
>>not met, then an implementation has to stop immediately and produce
>>an appropriate error message.", or whatever the usual wording for
>>draconic errors is in the XQuery spec.
>>I couldn't immagine the XML spec reading something like:
>>"Well-formedness is a prerequisite for the correct functioning
>>of XML. Enforcement of well-formedness is beyond the scope of
>>the XML specification.", and if it's not appropriate for XML,
>>then I can't see this being appropriate for XML Query.
>
>I think there are at least two reasons for not doing that.
>
>1. It may be extremely expensive to check some of these constraints. For 
>instance, some of our constraints might require every single node to be 
>examined, and most queries on the given data model instance may be 
>perfectly well defined, because the annotation of one particular node is 
>never needed by the query. When should the implementation stop and produce 
>the error if it never happens to look at that type annotation?

That looks like a good point.

Taking the text you originally cited:

>In order for XQuery to be well defined, the data model, the static
>context, and the dynamic context must be mutually consistent.

What about adding some phrase here at the end, e.g.:

In order for XQuery to be well defined, the data model, the static
context, and the dynamic context must be mutually consistent for
all the nodes of the data model that are used in the query evaluation.


>The
>consistency constraints listed below are prerequisites for correct
>functioning of an XQuery implementation. Enforcement of these
>consistency constraints is beyond the scope of this specification.
>This specification does not define the result of a query under any
>condition in which one or more of these constraints is not satisfied.



>2. Some implementations may have models that provide consistent behavior 
>in a less constrained environment than the one we describe. These may be 
>instructive for the future development of XQuery.

This is similar to saying that some implementations of XML parsers
may manage to get by without well-formedness, and that such parsers
may be instructive for the future development of XML. Doesn't sound
like a good idea to me at all.


>Some environments can assure a priori that they never encounter a data 
>model instance that does not meet these constraints, but some can not.

That's fine. We just want to make sure that the necessary constraints
are met, and don't care how they are met (or checked).


>>>Is that clear now? Can we close this issue, or is there an issue that I 
>>>am not aware of?
>>I may be misunderstanding what you want to say with the above text,
>>but in any case, I think the text needs to be fixed.
>
>I don't like the fix you suggest. Do you have a different suggestion for 
>fixing it?

I guess based on the input above, my proposal would be:

In order for XQuery to be well defined, the data model, the static
context, and the dynamic context must be mutually consistent for
all the nodes of the data model that are used in the query evaluation.
The consistency constraints listed below are prerequisites for correct
functioning of an XQuery implementation. If these consistency constraints
are not met, an XYZ error is produced.

[replace 'XYZ' with whatever is appropriate]


Regards,    Martin.
Received on Tuesday, 17 August 2004 07:52:53 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:45:20 UTC