This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 1755 - [FS] technical: 7.2 Standard functions with specific typing rules
Summary: [FS] technical: 7.2 Standard functions with specific typing rules
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Formal Semantics 1.0 (show other bugs)
Version: Last Call drafts
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Jerome Simeon
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-07-19 20:55 UTC by Michael Dyck
Modified: 2005-09-06 13:15 UTC (History)
0 users

See Also:


Attachments

Description Michael Dyck 2005-07-19 20:55:16 UTC
7.2 Standard functions with specific typing rules

It occurs to me that none of the inference rules in this section can be
applied in the normal way. E.g., if you have a FunctionCall of the form
    fn:remove($a,$b)
you can't just apply 7.2.11 (even though the FunctionCall matches the
rule's conclusion), because 'fn' might be bound to a different namespace.
Moreover, if you have FunctionCalls such as
    func:remove($a,$b)   or   remove($a,$b)
then if 'func' is bound appropriately, or the default function namespace
is set appropriately, you *do* want to apply 7.2.11, even though the calls
do *not* match the rule's conclusion.  This is a fair bit of fudging to
impose on the inference process.

One way to avoid the fudging would be to tweak each function to properly
check the function name. E.g., change each rule of the (rough) form:

    statEnv |- Expr : Type
    ----------------------
    statEnv |- fn:foo(Expr) : something(Type)

to (something like):

    QName of func expands to (URI,NCName)
    URI = "http://www.w3.org/2005/04/xpath-functions"
    NCName = 'foo'
    statEnv |- Expr : Type
    ----------------------
    statEnv |- QName(Expr) : something(Type)

Then the normal inference process would cause the rule to match in exactly
those cases that you want it to match.

However, that would be a pain. Here's (what I think is) a much better
solution. Currently, the rule-conclusions are judgments of the form

    statEnv |- QName (Expr1,...,Exprn) : Type

and thus are (apparently) alternatives to 4.1.5 / STA / rule 1. Instead,
make then judgments of the form

    statEnv |- expanded-QName(Type1,...,Typen) : Type

(See Bug 1575.) So rather than being alternatives to 4.1.5 / STA / rule 1,
they would be invoked *by* it, after it's already expanded QName (and
typed the arguments).  So now the rules would be alternatives to
4.1.5 / STA / rule (2|3).

Roughly speaking, you would need to change each rule from:

    statEnv |- Expr : Type
    ----------------------
    statEnv |- fn:foo(Expr) : something(Type)

to:

    URI = "http://www.w3.org/2005/04/xpath-functions"
    NCName = 'foo'
    ----------------------
    statEnv |- (URI,NCName)(Type) : something(Type)

or, with suitably-defined shorthand, to just:

    ----------------------
    statEnv |- (FN-URI,'foo')(Type) : something(Type)

(which is even more concise than the current, since it doesn't need
premises to get the types of the arguments).

I think this would work fine for all the functions in 7.2 except for
fn:collection and fn:doc, whose STA depends on the *form* of the argument,
not just its type. For those two, I suppose you could use the first
solution I suggested.
Comment 1 Michael Dyck 2005-07-19 23:25:14 UTC
(In reply to comment #0)
>
> I think this would work fine for all the functions in 7.2 except for
> fn:collection and fn:doc, whose STA depends on the *form* of the argument,
> not just its type.

Oh, and fn:subsequence.
Comment 2 Jerome Simeon 2005-07-27 15:22:45 UTC
I agree with the second proposed fix, beginning
"However, that would be a pain. Here's (what I think is) a much better
solution. Currently, the rule-conclusions are judgments of the form..."


Comment 3 Jerome Simeon 2005-08-31 15:32:03 UTC
The XML Query and XSLT WGs have accepted the bug, with the second proposed fix.
- Jerome