RE: Namespace prefixes for functions and operators considered con fusing

A personal response.

I have some sympathy with your comments, but...

I don't feel that the way we describe the semantics of operators in terms of
a mapping to hypothetical functions is enormously helpful to the reader, and
I have suggested in the past that it be changed. However, the working group
felt that although such a change might be an editorial improvement,
implementing the idea would involve a great deal of effort and risk
introducing errors, and decided not to go down this route. There's nothing
technically unsound in the current approach.

I would personally be in favour of having the core functions be in the null
namespace, as they were in XPath 1.0, and abandoning the notion of a default
namespace for functions. I think the introduction of the fn: namespace for
core functions gives very little benefit and is an unnecessary complexity.

However, the basic notion that functions are identified by a QName is I
think very useful. This is not a new idea, it was present in XPath 1.0, and
has proved very useful as a way of keeping vendor-defined and user-defined
functions clearly separated from functions in the core library. It has also
made possible the introduction of constructor functions for simple types
defined in a schema, which I think is a great convenience to users.

[And referring to your subsequent remark that the namespace recommendation
doesn't permit QNames to be used for objects such as functions: it doesn't
need to. It doesn't permit me to put milk in my coffee either. The
namespaces recommendation describes criteria used to decide whether an XML
processor or a document is or is not a conformant processor/document, and
that's all that it does. XSLT 1.0 stylesheets use QNames as the names of a
wide variety of types of objects that are entirely outside the scope of the
Namespaces recommendation, and XSLT 1.0 stylesheets are namespace-conformant
XML documents. The Namespaces Rec could have disallowed this practice (with
hindsight, some would argue that it should have disallowed it) by
disallowing all use of prefixes in element or attribute content, but it
didn't, and it's far too late to change that now.] 

Michael Kay


> -----Original Message-----
> From: Elliotte Harold [mailto:elharo@metalab.unc.edu]
> Sent: 15 November 2003 20:07
> To: public-qt-comments@w3.org
> Subject: Namespace prefixes for functions and operators 
> considered confusing
> 
> 
> 
> The whole "fn: is a function and is mapped to
> |http://www.w3.org/2003/11/xpath-functions| except when you
> actually use
> it (in which case no prefix is used), and op: looks like a namespace
> prefix but really isn't" is just a mess. It's a symptom of the 
> "everything must have a namespace and a URI" disease that has 
> infected 
> the W3C for the last few years. Removing the operators 
> namespace URI in 
> this draft has just made this more obvious. This whole 
> namespace mess is 
> horribly confusing.
> 
> Let's face reality: None of the functions or operators are in any
> namespace. The whole idea of putting these in a namespace 
> does not jibe 
> with the namespaces spec. Nothing is gained by claiming these 
> functions 
> and operators are in a namespace. Talking about the namespace of an 
> XQuery function has no more meaning than talking aobut the 
> current king 
> of France or the set of triangles with four sides.
> 
> The XQuery functions and operators spec will bemuch clearer
> if it does 
> not attempt to place any functions or operators in any 
> namespace. If you 
> wish to use the syntax fn: and op: to distinguish functions from 
> operators, that's OK. Alternately you could pick a different 
> delimiter 
> that does not remind anyone of namespace prefixes. For 
> example, fn# and 
> op#. However, fn: and op: should not be namespace prefixes, and in 
> reality they never really were.
> 
> --
> Elliotte Rusty Harold
>