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

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





------- Comment #4 from jmdyck@ibiblio.org  2006-04-21 20:52 -------
(In reply to comment #3)
> 
> The XQuery 1.0 document is very clear that the semantics of
> constructor functions are the same as a cast.

It's clear that the semantics of *something* relating to constructor functions
are the same as a cast, but it's not so clear what that something is. See
below.

> This is the actual definition:
> 
> [Definition: The constructor function for a given type is used to
> convert instances of other atomic types into the given type. The
> semantics of the constructor function T($arg) are defined to be
> equivalent to the expression ($arg cast as T?).]

A good example of lack of clarity. It *says* it's talking about the semantics
of the *function*, but it *looks* like it might be talking about the semantics
of the function *call* (and the latter is how you indicate it should be
interpreted). That's the distinction I was making in my previous comment. (It
would be clear if it said "The semantics of a call to the constructor
function...".)

> The semantics of function calls have a lot of things going on which
> are not happening for constructor functions, notably the function
> conversion rules.

Okay. I'm still curious if there are cases where the two interpretations would
lead to different results. 

....

> I just realized though that we could write the normalization rule as
> follows, making namespace resolution explicit. The second precondition
> checks that the QName is the name of an atomic type.
> 
>   statEnv |- QName of elem/type expands to expanded-QName
>   statEnv |- declare type QName restricts AtomicTypeName
>   -----------------------------------------------------------
>   statEnv |- [QName(Expr)]_Expr == [Expr cast as QName?]_Expr
> 
> [That usage for normalization rules is introduced in Section 3.2.2
> Normalization mapping rules.]
> 
> That may work better than just some english text. Any suggestion or
> preference on this?

I prefer the inference rule. But it needs some tweaking...

1)
As I pointed out in comment #2, the XQuery doc indicates that unprefixed
constructor function names are resolved according to the default function
namespace (not the default element/type namespace). Thus, "of elem/type expands
to" should be changed to "of func expands to".

2)
For "declare type", I think you mean "define type". But that means the judgment
is of the form
    statEnv |- Definition
which I don't think is valid. Instead, what you probably mean is something like
    statEnv.typeDefn(expanded-QName) = define type QName2 AtomicTypeDerivation
(Note that the QName in the Definition won't always be the same as the QName in
the FunctionCall, thus QName2.)

3)
Change '==' to '='. See Bug 1548.

4)
The occurrences of 'Expr' as an italicized word should really be 'ExprSingle'.

In sum:
    statEnv |- QName of func expands to expanded-QName
    statEnv.typeDefn(expanded-QName) = define type QName2 AtomicTypeDerivation
    -----------------------------------------------------------
    statEnv |- [QName(ExprSingle)]_Expr = [ExprSingle cast as QName?]_Expr


Given the above, you could make 4.1.5 / Norm / rule 1 more explicit and
complementary:

    statEnv |- QName of func expands to expanded-QName
    not( statEnv.typeDefn(expanded-QName) =
                  define type QName2 AtomicTypeDerivation )
    statEnv.funcType(expanded-QName,n) =
                  declare function expanded-QName(Type1, ..., Typen) as Type
    -----------------------------------------------------------
    statEnv |- [QName(Expr1,...,Exprn)]_Expr =
                  QName( [Expr1]_FunctionArgument(Type1), ..., etc )

Received on Friday, 21 April 2006 20:52:52 UTC