[Bug 1680] [FS] editorial: 4.12.5 Constructor Functions

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





------- Comment #2 from jmdyck@ibiblio.org  2006-04-12 09:51 -------
Even changing AtomicType to AtomicTypeName, it's still ungrammatical, because
AtomicTypeName doesn't exist in the XQuery grammar. (And even if it did, QName
wouldn't derive it.) So the left-hand side of the normalization rule will never
match a legal query, and the rule will never be invoked.

Clearly, a call to a constructor function is syntactically a FunctionCall, so
the rules of 4.1.5 have to deal with it at some point.

Moreover, the XQuery doc indicates that:
1) unprefixed constructor function names are resolved according to the default
function namespace.
2) the 'Function signatures' component of the static context (i.e.,
statEnv.funcType in the FS doc) contains signatures for constructor functions.

Thus, it should be well-defined to subject constructor names to
    QName of func expands to expanded-QName
and
    statEnv.funcType(expanded-QName,1) = declare function ...

The XQuery doc and the F+O doc appear to put constructor functions on an equal
footing with other built-in functions, which suggests that 4.1.5 should handle
them like other built-in functions.

However, those docs don't make it entirely clear whether a call to a
constructor function:
-- is a call to an actual (built-in) function, where the semantics of that
function happen to be defined in terms of a cast expr, or
-- is just a syntactic alias for a cast expr.

If the former, then 4.1.5/STA would probably want to add another item to the
list of 3:
    1.5 If the expanded QName for the function corresponds to one of the
        built-in constructor functions, the rules in [...] are applied.

If the latter, then the constructor-specific logic has to get control earlier
in the process, presumably in 4.1.5/Norm.

But are there any cases where the two interpretations lead to different
results?

Received on Wednesday, 12 April 2006 09:51:40 UTC