[Bug 4273] [FS] data on element()

http://www.w3.org/Bugs/Public/show_bug.cgi?id=4273





------- Comment #20 from jmdyck@ibiblio.org  2007-11-03 23:55 -------
To make this comment more concise, let me introduce the abbreviation:
    ct(foo) = "complex type with foo content"
where 'foo' is one of "complex", "mixed", "element-only", or "empty"

(In reply to comment #17)
> As Bill Patton has pointed out in a message to public-qt-comments, data on
> is not always defined.

I haven't been able to find his message about 'data on'. Could you provide a
pointer?

> Quoting FS:
> 
> "The data on filter is not defined on any element type whose type
> annotationXQ denotes a complex type of complex content and therefore
> applying data on to such a node raises a static error."
>
> He therefore concludes that fn:data applied to a value whose static type
> is known to be element() must necessarily raise a static type checking
> exception (because it is conceivable that the element supplied at runtime
> is has complex content).

Yes, the SequenceType element() matches any element node, including those
for which fn:data raises a type error, so type soundness dictates that
'data on' applied to the type denoted by element() must raise a type error.
Of course, this disagrees with the existing rules for 'data on', and also
disagrees with my proposed solution in Comment #16. And probably wouldn't
be very pleasant to work with.


> If however, this was replaced with:
> 
> "If ElementType denotes a complex type of complex content then the static
> type is 'none' and applying fn:data to such a node raises a dynamic error
> [err:FOTY0012]."
>
> ...
> The cases where 'data on' is 'none' is exactly the cases where fn:data is
> defined to raise the error [err:FOTY0012], ...

No, I don't think that's true. The snag (or one of them) is that a ct(mixed)
(Tm, say) can derive a ct(element-only) (Teo).  An element node with type
annotation Tm has a typed-value (and thus fn:data result) of type
xs:untypedAtomic, whereas an element node with type annotation Teo has an
undefined typed-value (and fn:data raises an error). But because of the
'derives-from' relation, Tm matches both nodes. So 'data on' applied to Tm
should "cover" both outcomes.

In fact, you pointed that out yourself when quoting Bill Patton: element()
denotes an element type with ct(mixed), and it matches all element nodes, some
of which have a type annotation that is a ct(element-only), and thus cause
fn:data to raise an error.

On the other hand, you suggested changing the error [err:FOTY0012] from a type
error to a dynamic error, and that might be most of the solution. It would mean
that static typing is no longer obliged to reflect the possibility of that
error. 

So my revised proposal is this:

(1) In the XQuery spec, sections 2.4.2 & 2.5.2, change FOTY0012 from a type
    error to a dynamic error.

(2) In the FS spec, section 7.2.6, Static Type Analysis:
    (2a) In the last rule, the one dealing with ct(mixed), change the result
         type from xs:untypedAtomic to xs:anyAtomicType* (as in Comment #16).
    (2b) Replace the last paragraph with a rule that says:
             When applied to an element type whose type annotation denotes
             a complex type of element-only content, the 'data on' filter
             returns the type 'empty'.

Received on Saturday, 3 November 2007 23:55:52 UTC