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

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





--- Comment #26 from Michael Dyck <jmdyck@ibiblio.org>  2009-02-07 21:46:33 ---
(Following up comment #23)
> In addition to the solution I proposed in Comment #20, there might be an
> alternative involving use of the "expands to" judgment, but I'm not sure
> what it would look like yet.

More specifically, I was thinking that rather than doing a necessarily
general case analysis on a (possibly) high-level type, we could construct
its "union interpretation", and then do a more specific case analysis
on each type in the union (and then take the union of the results).

I still believe this is possible, and would in some situations furnish a
more specific static type. However, writing the necessary inference rules
turns out to be harder than I thought (due to the way that the FS
represents information in the type hierarchy), and I'm not confident
that I'd get it right.

So, here is my summary of the situation:

 -- If there is to be no change to any document other than FS, then FS must
    be changed so that "data on element()" (among other things) raises a
    type error.

    E.g.,
       fn:data(<a>2</a>)
    would raise a type error under the Static Typing Feature.

 -- If that's unacceptable, then the minimal outside-FS impact is to
    change FOTY0012 from a type error into a dynamic error as described in
    comment #20.

    "data on element()" would then be xs:anyAtomicType* rather than an
    error, so, e.g.
       fn:data(<a>2</a>)
    would have static type xs:anyAtomicType*. But queries such as
        1 + <a>2</a>
    would still raise a type error during static analysis, as pointed out
    in comment #2.

 -- If that's still unacceptable, then I believe the next step would
    involve the introduction of a type such as "xs:typed" described in
    comment #7.

    If I understand correctly, that type would be the type annotation for
    unvalidated elements, and 'data on element(*,xs:typed)' would yield
    the wished-for xs:untypedAtomic. So it separates the two uses of
    xs:anyType pointed out in comment #5.

    However, this would be a fairly fundamental change to the XDM, F+O, and
    XQuery/XPath docs, and I suspect it would not be accepted as an erratum
    against 1.0/2.0.


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Saturday, 7 February 2009 21:46:43 UTC