- From: james anderson <james.anderson@setf.de>
- Date: Thu, 6 Nov 2003 19:17:16 +0100
- To: "Kay, Michael" <Michael.Kay@softwareag.com>
- Cc: Jonathan Robie <jonathan.robie@datadirect.com>, public-qt-comments@w3.org
On Thursday, Nov 6, 2003, at 18:32 Europe/Berlin, Kay, Michael wrote:
> > Here's a use case for casting to xs:QName. Suppose I write a
> > function that
> > creates an element with a given name:
> >
> > declare function make-empty-element($n as xs:QName)
> > as element()
> > {
> > element { $n } { }
> > }
> >
> > Now I want to be able to call this function. Sensibly, my
> > function requires
> > a QName for the element name, so it can only be called with
> > this type of
> > parameter. Now I want to call this function to create an
> > element named
> > "james". To do this, I need to cast a string to a QName:
> >
> > let $n := xs:QName("james")
> > return make-empty-element( $n )
> >
>
> This is certainly a good use case. However, it's interesting that the
> argument to the xs:QName constructor is a string literal. But actually
> any expression that yields a string can be used here.
is there any difference in the capability offered by a function which
took the iri and local part as two distinct string data.
> I don't think there's a convincing use case for constructing a QName
> dynamically, using the namespace bindings that are declared
> statically. If you did want to construct a QName dynamically, I think
> you would want to construct it from the namespace URI and local-name,
> using the fn:expanded-QName() function.
furthermore, if that is available, is there any case which it does not
suffice.
>
> The case that causes the pain is the function that makes run-time use
> of namespace prefixes declared in the query, because it means that
> implementors have to keep the static namespace context around at
> run-time.
they not only cause pain, they will eventually break the model.
> I don't think we would lose anything if we restricted this
> constructor to take a string-literal, or alternatively if we provided
> syntax such as #james or #my:name to denote a literal QName value. I'm
> not generally in favour of arbitrary restrictions,
it is _not_ an arbtrary restriction. is removes a case where the
operators do not close over the model.
> but it does seem to me that the namespace prefixes declared
> statically in the query (like the variable names and the function
> names) are something that ought to exist at compile time only.
yes, and at compile time they are constant folded to the iri bound to
the respective lexically apparent prefix. after which the requirement
to afford the lexical bindings indefinite extent disappears.
>
> (XSLT makes use of dynamically constructed lexical QNames all over the
> place, and I think it's a mistake,
deprecate it. provide an operator which takes an iri and a local part
as an alternative.
there should be _no_ formal difference in terms of expressiveness
between binding an iri to a prefix and binding an iri to a variable.
after fixing enough bugs devolve to incorrect or nonexistent prefix
bindings, any sane programmer would stop using them and evolve to using
a variable with an iri value.
> although it's too late to change it).
>
> Michael Kay
>
Received on Thursday, 6 November 2003 13:17:53 UTC