Advancing with XQuery article

[James Fuller]

On Wed, Oct 1, 2008 at 12:25 PM, Michael Kay <http://x-query.com/mailman/listinfo/talk> wrote:
> Good article. A few comments:

thank you

> 1>XQuery allows you to bind a prefix to an empty string to indicate placing
> an
> element into the default element namespace
>
> I don't think that's correct.
>
> declare namespace p = "";
>
> makes p unavailable for use. To quote: "If the URILiteral part of a
> namespace declaration is a zero-length string, any existing namespace
> binding for the given prefix is removed from the statically known
> namespaces. "

I think I have conflated some of the finer points of what the spec
says and what XQuery processors actually do.

Its important to note that the original article and source code was
written against several XQuery processors which I think has
contributed to some slight differences. That being said, I still think
that most of the article is 'true' in a 'dwim' sense as to what
happens when you are actually using XQuery.

I will go see why I said this once I get the chance to run it against
the various XQuery processors again.

> 2>If you had a system-property() function, it would be relatively easy to
> implement
> XQuery function libraries made up of XQuery processor specific functions.
>
> It wouldn't actually help much, because the function bindings would still
> fail. You need a compile-time conditional, like XSLT 2.0's use-when (or some
> analog to xsl:import).

yes, but system-property() does help in writing checks for software
... probably would have helped to explicitly say that this would be
useful in creating tests or a self check for
installation/configuration versus dynamic runtime of code that 'does
something useful'.

However, I don't think u will convince me that not having the function
is a benefit (which btw I don't think u are doing)... it is useful in
XSLT and I think it would be useful in XQuery.

>
> 3>fn:not(fn:deep-equal($a,$b))
>
> Why do so many people use the "fn:" prefix, it seems totally unnecessary?

I always use the 'less touch typing is better' principle ... though I
think I simply looked at the various specs and decided to blindly
follow.

> 4>Note: It's been kindly pointed out to me that these functions can check
> equality of
> datatypes as well
>
> I'm not sure what you mean by that, but it seems misleading. Datatypes
> aren't values and can't be compared. And if you mean that deep-equal()
> requires two values to have the same type, it doesn't - a decimal can still
> compare equal to a double.

I disagree that it is misleading people; I agree that I should
probably explicitly state that this type of comparison is useful
sometimes in unit testing scenarios. I find this kind of testing of
basic assumptions especially true in immature technologies where
processors across the spectrum are not 100% compliant or stable.

> 5>fn:not(fn:boolean(fn:compare($a, $b)))
>
> Can't see why you would want to do this rather than using "eq". If you want
> to force codepoint collation, use a third argument to compare(), or use
> codepoint-equal().

serious brain cramp here ... of course u are right

> 6>Note that this is a naive implementation of assertion (for example, even
> when disabled, it still calls the test:assert function, albeit with almost
> no
> processing cost).
>
> In Saxon there should be zero run-time cost - if($DEBUG) then ... else -
> gets optimized at compile time if DEBUG has a constant value. (In fact, a
> number of your examples will probably be evaluated entirely at compile time
> - check by using -explain.

yes, I defer back to original code which I had written across several
XQuery processors ...

>
> 7>As with the local:factorial example, you have a tail recursive function.
>
> No, the treewalker function is not tail-recursive. The recursive call is
> nested inside an element constructor which is itself inside a for loop. (But
> since the recursion depth is the depth of the XML tree, this doesn't
> matter.)

ugggg ... forgot about the element constructor bit ... thx for
pointing out where I got this completely wrong .... other XQuery
processors seem to have inferred tail recursion on such constructions
(I would say some pretty optimistic xquery optimization in effect).

I hope the principle is clear, just need to get the source code
slightly amended ;)

> 8>filter.xq
>
> Saxon will probably optimize this to
>
> declare function local:filter($func, $seq as item()*) as item()* {
>  $seq[saxon:call($func, .)]
> };
>
> but I wonder why you didn't write it that way? It seems to be the common
> XQuery trap of using complex FLWOR expressions where simple XPath
> expressions will do.

I used to be constantly switching between FLWR and XPATH and found the
results somewhat unreadable (for me). So what I do now is write FLWR
form first, then if I have the time go back and optimize with XPATH.

enough of my excuses, many many thanks for taking the time to read the
article and thanks once again for the fantastic XQuery processor.

cheers, Jim Fuller