ISSUE: XQuery 'constructor' syntax.

To avoid adding lexical rules for literals to XQuery, the Functions &
Operators document currently defines a number of 'constructors' for
simple types.  For example, 'xf:duration("P1Y")' constructs a duration
of one year.

There is currently the restriction that constructors must have literal
(constant) arguments.  That is, you cannot call 'xf:duration($str)' or
'xf:duration(concat("P","1Y"))'.

If this is true, why make it look like a function call?

Users will expect the function call syntax to denote function calls.
Users will have to be educated that the function calls that construct
values are not actually function calls, but special 'constructor'
syntax that must take a literal.  It seems an unneccessary burden.

---

It seems likely to me that users will see this:

    xf:duration ("P1Y")

and think that it might be reasonable to write this:

    let $s := "P1Y" return
    xf:duration ($s)

rather than the surreal alternative provided:

    let $s := "P1Y" return
    cast as xs:duration ($s)

Why create this confusion?

---

There is, in fact, a whole parallel mechanism in the spec
called 'cast' that can parse values from strings.  You can
write:

   cast as xs:duration ("P1Y")
OR
   cast as xs:duration ($str)

It seems odd that parsing strings get a special new syntax,
while a *literals* gets to use a function-call syntax.

---

There seem to be three reasonable alternatives:

   1. Define a lexical syntax for each type of literal.

      This would in some ways be the least surprising.

      Unfortunately, there are so many disjoint literal types in XQuery
      that it is understandable why this wasn't the choice taken.

   2. Design a special syntax like (strawman syntax only!):

         construct xs:duration { P1Y }

      Or, if you don't want to have funny lexical rules,

         construct xs:duration { "P1Y" }

      This would at least have the advantage that constructors don't
      look like function calls, and resolves the lexical issues.

   3. Define a function that takes a string and parses it, and don't
      have a literal syntax at all.

      Note that this function can be called at compile-time if it is
      called with a literal argument, so it can't simply be a matter of
      efficiency.  An implementation note could even require/recommend
      this optimization, if necessary.

      This would be my preferred option, in any case.

      This option requires no dramatic changes to the current syntax,
      and does not have the unpleasant confusion.

      It could (and perhaps should) be mandated that these functions be
      invoked at query compilation time if the argument is a constant
      string.

---

In summary, please either make constructors real function calls, or
give them a syntax that doesn't imply that they are.


Thank you very much for your time.
       -Shawn Vincent.


--
Shawn Vincent, svincent@exalt.com
Exalt Inc.

Received on Monday, 14 January 2002 10:34:12 UTC