Fallback conversions - Inconsistency between XPath 2 spec and XQuery Formal Semantics

My company (Decisionsoft Ltd) is working on an open source
implementation of XPath 2, using the latest Working Drafts.

As regards fallback conversions there seems to be an inconsistency
between XML Path Language (XPath) 2.0 (W3C Working Draft 16 August
2002) [XPath spec] and XQuery 1.0 and XPath 2.0 Formal Semantics (W3C
Working Draft 16 August 2002) [Formal spec].

Now, according to [XPath spec]:

>From 2.4.3.1 Atomization

This atomization process is used in the following cases:

      Arithmetic expressions
      Comparison expressions
      Function calls and returns
      Cast expressions

and, from the atomization process

...

* In any other case, atomization raises a type exception.

Now, in the flexible execution policy, this type exception causes a
fallback conversion to occur. A fallback conversion requires a
`required type'

2.4.3.3 Fallback Conversions [XPath spec]
...
* If the required type is boolean ...


Now, this required type can be ambigious in the case of Arithmetic and
Comparison expressions and the fallback conversion process often does
extra unnecessary casting in a Cast Expression (I add some details
showing the problems at the end of this mail).

These problems are avoided by [Formal spec] which defines two types of
atomization, one with a required type and throwing type exceptions and
one without a required type which throws errors.

The required type parameterised version is only used in [Formal spec]
for function calls, all other situations use the unparameterised
atomize.

Hence, it seems that [Formal spec] is correct and [XPath spec]
incorrect. Is this the case?

Thanks for your attention.

Regards,

Tom Ford

---

Inconsistencies with [XPath spec] atomize

The required type is unclear in a number of the situations stated
above.

I will use the syntax ( xs:integer(1), ... ) to mean a multiple item
sequence containing the first item which is specified.


`Arithmetic expressions' are the most ambigious case.

For the expression:

      ( xs:date("1999-10-26"), ... ) - ( xs:string("1999-10-26"), ... )

It is unclear which the required types are from the three possible
cases:

xs:date       xs:date
xs:date       xf:yearMonthDuration
xs:date       xf:dayTimeDuration

If the correct proceedure is to attempt to construct each of these
types in order until one is found that works, then this should be
stated.


`Comparison expressions' (3.5.1) appear to only act between the same
types (eg. A eq B xs:date xs:date).

With an expression comparing 2 sequences such as:

      ( xs:date("1999-10-26"), ... ) eq ( xs:string("1999-10-26"), ... )

it is unclear whether to assume the required type is `xs:date' or
`xs:string'.


`Cast expressions' (3.10.2) do have an associated required type (a
Sequence Type) however I do note that in the flexible environment with
the expression

cast as xs:date ( ( xs:string("1999-10-26"), ... ) )

Casting from xs:string -> xs:date will actually be performed in the
fallback conversion before the cast as operator is actually called

(2.4.3.3 fallback conversions) 

5. Otherwise if the given value is a sequence containing more than one
   item, only the first item is retained. If this item is a node, its
   typed value is extracted. If the typed value of the node is a
   sequence of more than one atomic value, only the first of these
   atomic values is retained. The resulting (supplied or extracted)
   atomic value is converted to the required type according to the
   rules in the following table (table from Functions & Ops).

-- 
Tom Ford, Software Engineer           DecisionSoft Ltd.
Telephone: +44-1865-203192            http://www.decisionsoft.com
Pathan Open Source XPath 2:           http://software.decisionsoft.com

Received on Thursday, 19 September 2002 09:11:23 UTC