Re: Bug 4378: absent context item

Thanks for the proposal.  Some comments inline...

> On Nov 3, 2015, at 10:40 AM, Michael Kay <mike@saxonica.com> wrote:
> 
> The question is: what kind of error should we raise when we need a context item and the context item is absent? And where and how should we describe the rules?
> 
> I’m concerned that we have a solution that works for the full range of specs: XQuery, XPath, and XSLT.
> 
> I think the best way to achieve this as follows:
> 
> (A) If we’re going to build this on the concept of “context item static type” then we need to strengthen the foundations. In XSLT there are contexts, for example the body of a named template, where the best we know statically is that the context item is “either item() or absent”. There may even be cases where we know statically that the context item is “either node() or absent”. I don’t propose to do this formally, but I suggest we add to the definition of “context item static type”: 
> 
> The context item static type is either an item type, or the value “absent” indicating that the context item does not exist, or the union of the two (for example, it might be “either node() or absent”).
> 

I think this may confuse XPath and XQuery users.  The "context item static type" is one of many context components where the value may be absent just like the *context item*, *default element/type namespace*, etc.  This seems to imply that absent is part of the type value somehow.  

For XQuery and XPath, I think there is only one case where the “context item static type” can be absent and that is in the static context of a function body.  And, there is no case where a type may or may not be absent (e.g. the “either node() or absent” case is not possible)

> (B) In 2.2.3.1 we have:
> 
> <quote>
> If the Static Typing Feature is in effect, a processor must raise a type error during static analysis if the inferred static type of an expression is not subsumed by the required type of the context where the expression is used. For example, the call of substring above would cause a type error if the inferred static type of $a is xs:integer; equally, a type error would be reported during static analysis if the inferred static type is xs:anyAtomicType.
> 
> If the Static Typing Feature is not in effect, a processor may raise a type error during static analysis only if the inferred static type of an expression has no overlap (intersection) with the required type: so for the first argument of substring, the processor may raise an error if the inferred type is xs:integer, but not if it is xs:anyAtomicType. Alternatively, if the Static Typing Feature is not in effect, the processor may defer all type checking until the dynamic evaluation phase.
> 
> </quote>
> 
> After these paragraphs, add:
> 
> <quote>
> These rules are extended in the case of expressions that depend on the context item to handle the case where the context item is (potentially) absent:
> 
> * If the Static Typing Feature is in effect, a processor must raise a type error during static analysis [errorref] if the context item static type for such an expression includes the value “absent”.
> 
> * If the Static Typing Feature is not in effect, a processor may raise a type error during static analysis [errorref] if the context item static type for such an expression is the value “absent”.
> </quote>

I think you must mean to say “where the context item static type is (potentially) absent”?  I don’t understand why we need to complicate the static typing feature cases.  Could we add the special case earlier in 2.2.3.1?  I think this would be more logical since this special case would likely be detected before analyzing required types, type intersection, etc.

Earlier in 2.2.3.1 it says: 

<quote>
During the static analysis phase, a processor may perform type analysis. The effect of type analysis is to assign a static type to each expression in the operation tree. [Definition: The static type of an expression is the best inference that the processor is able to make statically about the type of the result of the expression.] This specification does not define the rules for type analysis nor the static types that are assigned to particular expressions: the only constraint is that the inferred type must match all possible values that the expression is capable of returning.
</quote>

After this 

<quote>
Processors may raise a type error during static analysis if an expression relies on the context item and the context item item static type is absent.  For example, the context item static type is absent in the static context of a function body.  
</quote>

I used “relies on” instead of “depends on” since I found similar language in section 2.1.2:

<quote>
If evaluation of an expression relies on some part of the dynamic context that is absentDM31, a dynamic error is raised [err:XPDY0002]. 
</quote>

Then in the incompatibility section I would say something like:

> “If an expression relies on the context item and the context item static type is absent, processors are able to raise an error during static analysis. This may affect applications that use try/catch to recover from this situation dynamically”.


Changing existing error codes seems too disruptive to me so this is all I would change.

Thanks,
Josh

Received on Tuesday, 3 November 2015 21:02:45 UTC