- From: Kay, Michael <Michael.Kay@softwareag.com>
- Date: Fri, 12 Dec 2003 00:16:04 +0100
- To: Xavier Franc <xfranc@online.fr>, public-qt-comments@w3.org
> > Some remarks about the treatment of namespaces for function > and variable names: I assume you are talking here about XQuery, and not about XSLT, though some of the remarks apply to both. > > * There is a strange asymmetry between functions and variables: The main reason for the asymmetry is that there is a library of over 100 built-in functions, and there are no built-in variables. This isn't to say that the design is perfect (there are aspects of it that I'm not especially keen on), but just to explain why the two cases are different. My personal preference would be for the rule that the standard functions are in no namespace, and user-defined functions must always be in a namespace, and must therefore always be prefixed. I did propose at one time that we should have something more Java-like, namely a list of namespaces that would be searched for unprefixed names, but everyone felt this was departing too far from the XML namespace model. Michael Kay > > - functions have a default namespace, variables haven't. > > - function declared in a main module must have the 'local' prefix, > while variables are allowed to be in the empty namespace. > > - (editorial remark) nothing is said about the > namespace/prefix of a function > declared in a library module (it must probably also match the > namespace of the module, but that should be made explicit) > > - it sounds odd that "All variable names declared in a > library module *must be > explicitly* qualified by the namespace prefix of the > module's target namespace." > > Wouldn't it be simpler to force this namespace if no > prefix is specified ? > This is a common practice in most programming languages. > that is, in the following example the variable $v would > be automatically in > namespace X: > > module namespace x = "X"; > declare variable $v { ... } > > * the name resolution mechanism in force is rather > rudimentary: this "default > namespace" system was perfectly justified for XML > elements, because element > names are not ncessarily declared (therefore a more > sophisticated mechanism > wouldnt work), but it seems hardly justified for variables > and functions of > a modern programming language. > Imagine I have to write "java.lang.String" each time I use > String in Java, > or even worse that I must first declare a prefix to be > expanded into "java.lang." > and put it in front of String ! (something like java:String) > > It is certainly too late to change this in XQ, but I > wanted to say it: > there is no fundamental necessity of a "default function > namespace" ! > > > * In: 4.5 Default Namespace Declaration > > This sentence seems both odd and superfluous: > "The effect of declaring a default function namespace is > that all functions in the > default function namespace, including implicitly-declared > constructor functions, are > *aliased with a name that has the original local name, but no > namespace URI.*" > > > -- > Xavier FRANC >
Received on Thursday, 11 December 2003 18:17:35 UTC