Re: Bug 4378: absent context item

> 
> 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)

What about the outermost expression (which in XPath means pretty well everywhere)?

In XQuery, if you specify “declare context item as node() external;”, with no default, there’s nothing in the spec that says it’s mandatory to supply a context item. Saxon’s interpretation of that declaration is “if there is a context item then it must be a node”, i.e. the type is “node() or nothing”. That’s consistent with the fact that it’s a dynamic error if you reference the context item and no context item is supplied: in XQuery 3.0, you can catch this error, which is why there’s a compatibility issue. 

If you don’t have a context item declaration, then I think all bets are off. And for XPath, definitely, all bets are off.

Example query:

try { document-uri(.) } catch (err:XPDY0002) { error(“No input document supplied") }

In XSLT 3.0 our equivalent to the context item declaration is

<xsl:global-context-item as=“item-type” use=“required | optional | absent”/>

so we are quite explicit about the case where the context item is mandatory, and we are explicit that you can declare it to be a “node() or nothing”. A stylesheet can have multiple entry points, which might have differing requirements on the context item, so the “optional” case is important.

<xsl:template match=“/“>
   ….
</xsl:template>

<xsl:template name=“main”>
  <xsl:apply-templates select=“doc(‘standard-input.xml’)”/>
</xsl:template>

We need to be very careful when we say that "the context item static type is absent” as to whether this means “there will be no context item”, or “we have no information about the type of the context item”. When we say this in connection with function bodies, we mean “there will be no context item”. When we say it at the top level of the query, we mean “we have no information”.

Michael Kay
Saxonica

> 
>> (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.

I’m happy to make that change. I don’t think I was complicating things, only explaining the complexities that are already there, but we can brush them under the carpet if you prefer…

Michael Kay
Saxonica

> 
> 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 Wednesday, 4 November 2015 08:48:52 UTC