Reserved namespaces, and QNames as extension keywords

[Pavel Minaev]

On Mon, Apr 20, 2009 at 3:47 PM, G. Ken Holman
<http://x-query.com/mailman/listinfo/talk> wrote:
>> 1) The spec requires every module and schema to be associated with a
>> namespace, and seemingly doesn't restrict the value domain for such
>> namespaces (except for restricting clashes between several
>> modules/schemas imported within a single query).
>
> Correct.  A namespace is just a URI string and there are no constraints on
> the strings based on module importation.
>
>> Can an XQuery
>> implementation go further than that, and reserve specific namespaces
>> for its own use, not allowing programmer to define his modules and
>> schemas within that namespace at all? (but, e.g., providing some
>> additional predefined types available from such namespaces without any
>> "import schema" declarations).
>
> Not that I know of from my read of the specification.

I wonder if it makes at least some implementations not compliant in
that respect, then - e.g. Saxon seems to reserve certain namespaces to
map to Java/.NET types.

>> 2) Assuming the answer to #1 is true, is it legal for a conforming
>> XQuery implementation to use QNames from such a reserved namespace as
>> "keywords" (i.e. syntax elements for extension language constructs),
>
> The only expression extension allowed is the pragma and the pragma only has
> influence over its associated expression:
>
>  (# pragma here #) { (:associated expression here:) }

Technically, a pragma expression can well be {()} or even {error((),
"Not supported")}, and the pragma itself can contain an XQuery
expression (possibly extended in some way).

>> I.e. something along the lines of:
>>
>>  declare namespace ext = "...";
>>
>>  declare variable $f
>>  as ext:function(xs:integer, xs:integer => xs:integer) (* custom type
>> keyword *)
>>  := ext:lambda($x as xs:integer, $y as xs:integer) as xs:integer { $x
>> + $y } (* custom syntactic construct *)
>
> For future reference, the comment facility uses "(: comment :)" syntax.

Yes, sorry about that. I get it mixed up with ML all the time.

>> I am aware of pragmas and "declare option", but, obviously, they are
>> much more limited - in example above, ext:lambda could possibly be a
>> pragma, though that would complicate nesting; but I don't see any way
>> to use extensibility mechanisms explicitly spelled out in XQuery spec
>> for something like ext:function.
>
> It is unclear to me what benefit or feature you are trying to get with the
> ability to declare keywords.  How are keywords better than function calls?
>  What problem are you trying to solve?

The problem (well, one of the problems) I'm trying to solve is
demonstrated in my example - first-class function literals. Defining
values of that type is possible using eval-like functions which take a
string, e.s.:

  ext:lambda("($x as xs:integer, $y as xs:integer) as xs:integer { $x + $y }")

But this, in my opinion, is a very ugly solution, since it causes all
types of problems with precompiling implementations, as well as IDEs.
It's also more lax than it needs to be, because in this case,
ext:lambda would have to be able to handle any valid string passed to
it at run-time; ideally, I'd want it to be a construct that it
entirely handled strictly at compile-time.

As I've pointed out in my previous post, pragma is a viable
alternative here, though it has problems with nesting (since one can't
nest a pragma inside another pragma - the outer pragma will terminate
at the first occurence of "#)"). But for e.g. first-class function
types extension, I don't see any real options aside from introducing
new syntax.

>> If the existing spec explicitly disallows such things, then I would
>> like to propose enabling them in future XQuery versions; maybe with a
>> new special construct to declare such "extensibility" namespaces for
>> extra clarity, e.g.:
>>
>>  declare extension namespace ext = "...";
>
> To address what use case that is not already addressed by the language?

See above. Basically, it would allow for extensibility points outside
expression context (which is covered by pragma) - in particular, for
type references. Aside from function types and lambdas, I can think
about a few other use cases. E.g.:

  (: Foreign type system integration :)
  declare function local:foo($obj as java:ref(java.lang.Object)) { ... }

  (: Parametric polymorphism extension :)
  ext:forall(a)
  declare function seq:every-second($x as ext:type-parameter(a)*) as
ext:type-parameter(a)* { ... }

I don't see why it's any more problematic than e.g. "declare option",
which already introduces the possibility of queries using
implementation-specific features with no fallback option (unlike
pragmas).