- From: james anderson <james.anderson@setf.de>
- Date: Mon, 27 Oct 2003 18:02:50 +0100
- To: public-qt-comments@w3.org
On Monday, Oct 27, 2003, at 16:11 Europe/Berlin, Kay, Michael wrote:
> > > There are still a few situations in XQuery where the static
> > namespace
> > > context needs to be retained at run-time. An example is in computed
> > > element constructors where a construct such as the following is
> > > permitted:
> > >
> > > element { if (b) then "b:name" else "c:name" } {3}
> >
> > this is not a use case.
>
> I didn't say it was a use case. I only pointed it out as an example of
> where the current facility is used, and where some people might argue
> that the extra convenience to the user is worth the inconvenience to
> the implementor.
if the impression has arisen, that i am reiterating my concerns in
order to avoid "inconvenience" as an implementor, please allow me to
state clearly that "inconvenience" is not, in itself, the issue.
my concern is that the new versions of the specification introduce
requirements which will inevitably reduce the capacity of a model which
conforms to those requirements. until now, it has been possible to
implement xml/xpath/xquery processors which would produce correct
results in the general case. the additions in more recent specification
drafts which stipulate the handling of namespaces will preclude such
implementations.
my argument is that it is a mistake to do this in order only to support
syntactic constructs for which there are obvious and easily used
equivalents. that is why i am asking for use cases. perhaps there is
some way the standard writers envision that xpath/xquery would need to
be used which requires such expressions. to date there has been no
demonstration of such a use.
> This is a balance we have to weigh up all the time, and it is silly
> to pretend that there is an obviously correct answer.
perhaps, but sometimes the wrong answers are obvious.
...
Received on Monday, 27 October 2003 13:14:11 UTC