[Bug 1580] [FS] technical: 4.1.5 Function Calls: complicated by pseudo-functions

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





------- Additional Comments From jmdyck@ibiblio.org  2005-07-21 04:25 -------
More explicitly:

    statEnv.funcType:
        This should map an (expanded-QName,arity) pair to a single
        function signature. Change the rules in 4.1.5 appropriately.
        For the "pseudo-functions", supply a suitably general signature
        (although it doesn't really matter since they have special STA
        rules anyhow).

    4.1.5 / STA / rule 2:
        Indicate that 'expanded-QName' is that of a pseudo-function.
        Move the resulting rule to B.2.

    4.1.5 / STA / rule 3:
        Remove the 'not' premises.

    B.2
        Add these rules:

            [expanded-Qname is that of a binary pseudo-function]
            Type1 is not a union of atomic types
            Type2 is not a union of atomic types
            statEnv |- Type1 can be promoted to Type1'
            statEnv |- Type2 can be promoted to Type2'
            operator type for Type1' and Type2' is Type3'
            --------------
            statEnv |- expanded-QName(Type1, Type2) : Type3'

            [expanded-Qname is that of a unary pseudo-function]
            Type1 is not a union of atomic types
            statEnv |- Type1 can be promoted to Type1'
            operator type for Type1' is Type3'
            --------------
            statEnv |- expanded-QName(Type1) : Type3'

        Rewrite the existing B.2 / STA as instances of
            statEnv |- expanded-QName(Type1, ...) : Type
        instead of
            statEnv |- QName(Expr1, ...) : Type
        (See Bug 1755.)

        Clarify the interaction/relationship between the rules handling
        promotion and the rules handling optionality.

Received on Thursday, 21 July 2005 04:25:13 UTC