RE: [XPath] Dynamic Errors and first-item semantics

I agree with your first comment, but I do not think that the first-item
semantics was meant to be acceptable in your example below...

Michael

> -----Original Message-----
> From: public-qt-comments-request@w3.org [mailto:public-qt-comments-
> request@w3.org] On Behalf Of Michael Kay
> Sent: Wednesday, February 18, 2004 2:26 AM
> To: public-qt-comments@w3.org
> Subject: [XPath] Dynamic Errors and first-item semantics
> 
> 
> 
> Sections 2.5.2 and 2.5.3 of the XPath book talk about "dynamic
errors",
> but what they say is equally applicable to type errors raised during
the
> evaluation phase. The examples make this clear: consider "For example,
> if a function parameter is never used in the body of the function, an
> implementation may choose whether to evaluate the expression bound to
> that parameter in a function call." For this example to be correct,
the
> section must apply to all run-time errors, not only to so-called
> "dynamic errors".
> 
> (The problem arises because of poor choice of terminology. We tend to
> imagine that all run-time errors are dynamic errors, but they are
not.)
> 
> While we are on the subject, here is a request for clarification.
> 
> The expression concat("Title:", //title) raises a type error if the
> document contains more than one <title> element.
> 
> Section 2.5.3 says:
> 
> "an implementation is not required to search for data whose only
> possible effect on the result would be to raise an error"
> 
> Assuming that section 2.5.3 applies to type errors as well as to
dynamic
> errors, does this mean that in the above expression, the
implementation
> can output the value of the first <title> element in the document, and
> avoid searching for any others?
> 
> If so, we have reintroduced the first-item semantics of XPath 1.0 (and
> the corresponding efficiency) by the back door, and we should make
this
> explicit, at least by including an example.
> 
> Michael Kay

Received on Wednesday, 18 February 2004 11:43:34 UTC