[xquery-talk] xquery 3.1 wishlist

[W.S. Hager]

Hello,

I've been working with the recent xquery 3.1 implementation in the develop
branch eXist-db. I encountered some cases that were quite hard to work
around:

- the lack of array:index-of()
- the lack of the iterator index in arrayfor-each and related higher-order
functions

Perhaps someone of the workgroup is available to discuss those cases.

Thanks,
Wouter
--
W.S. Hager
Lagua Web Solutions
http://lagua.nl

[Michael Kay]

I would think both of these could be implemented as user-defined functions but it’s hard to know without seeing a specification: saying you want a function called array:index-of() is not very informative unless you explain exactly what you want the function to do.

If it’s to behave like fn:index-of() then you can write it as

array:index-of($array, $value) {
(1 to array:size($array))[ $array(.) = $value ]
}

which is hardly a great hardship to write as a user-defined function.


Michael Kay
Saxonica

Post by W.S. Hager
Hello,
- the lack of array:index-of()
- the lack of the iterator index in arrayfor-each and related higher-order functions
Perhaps someone of the workgroup is available to discuss those cases.
Thanks,
Wouter
--
W.S. Hager
Lagua Web Solutions
http://lagua.nl <http://lagua.nl/>
--
W.S. Hager
Lagua Web Solutions
http://lagua.nl <http://lagua.nl/>
_______________________________________________
http://x-query.com/mailman/listinfo/talk

[W.S. Hager]

Hi Micheal,

Agreed, it could be implemented as a user-defined function (although this
particular solution currently throws an error in eXist). However, what
bothers me is that fn:index-of(1,2,[3,4], 3) may lead to unexpected
results, because the array is flattened. I get the impression that
array-specific semantics are sacrificed here, where in other cases they
aren't, and the dividing line is still unclear me.

Thanks,
Wouter

Post by Michael Kay
I would think both of these could be implemented as user-defined functions
but it’s hard to know without seeing a specification: saying you want a
function called array:index-of() is not very informative unless you explain
exactly what you want the function to do.
If it’s to behave like fn:index-of() then you can write it as
array:index-of($array, $value) {
(1 to array:size($array))[ $array(.) = $value ]
}
which is hardly a great hardship to write as a user-defined function.
Michael Kay
Saxonica
Hello,
I've been working with the recent xquery 3.1 implementation in the develop
branch eXist-db. I encountered some cases that were quite hard to work
- the lack of array:index-of()
- the lack of the iterator index in arrayfor-each and related higher-order functions
Perhaps someone of the workgroup is available to discuss those cases.
Thanks,
Wouter
--
W.S. Hager
Lagua Web Solutions
http://lagua.nl
--
W.S. Hager
Lagua Web Solutions
http://lagua.nl
_______________________________________________
http://x-query.com/mailman/listinfo/talk

[W.S. Hager]

Correction: fn:index-of([1,2,[3,4]], 3)

Post by W.S. Hager
Hi Micheal,
Agreed, it could be implemented as a user-defined function (although this
particular solution currently throws an error in eXist). However, what
bothers me is that fn:index-of(1,2,[3,4], 3) may lead to unexpected
results, because the array is flattened. I get the impression that
array-specific semantics are sacrificed here, where in other cases they
aren't, and the dividing line is still unclear me.
Thanks,
Wouter

Post by Michael Kay
I would think both of these could be implemented as user-defined
functions but it’s hard to know without seeing a specification: saying you
want a function called array:index-of() is not very informative unless you
explain exactly what you want the function to do.
If it’s to behave like fn:index-of() then you can write it as
array:index-of($array, $value) {
(1 to array:size($array))[ $array(.) = $value ]
}
which is hardly a great hardship to write as a user-defined function.
Michael Kay
Saxonica
Hello,
I've been working with the recent xquery 3.1 implementation in the
develop branch eXist-db. I encountered some cases that were quite hard to
- the lack of array:index-of()
- the lack of the iterator index in arrayfor-each and related
higher-order functions
Perhaps someone of the workgroup is available to discuss those cases.
Thanks,
Wouter
--
W.S. Hager
Lagua Web Solutions
http://lagua.nl
--
W.S. Hager
Lagua Web Solutions
http://lagua.nl
_______________________________________________
http://x-query.com/mailman/listinfo/talk

--
W.S. Hager
Lagua Web Solutions
http://lagua.nl

[Michael Kay]

Agreed, it could be implemented as a user-defined function (although this particular solution currently throws an error in eXist). However, what bothers me is that fn:index-of(1,2,[3,4], 3) may lead to unexpected results, because the array is flattened. I get the impression that array-specific semantics are sacrificed here, where in other cases they aren't, and the dividing line is still unclear me.

Arrays will give unexpected results, full stop. We spent two years trying to find a design that didn’t have unexpected results, and we failed. Start with the fact that $A[1] returns the whole array, and that you can’t iterate over arrays with FLWOR expressions. Arrays are grafted on to the data model as an afterthought, and it shows right through. That’s not for want of trying: we were running out of names for all the different ideas we rejected as unworkable.

The choice of functions in the library is inevitably arbitrary. I think we found that if you wanted a completely minimalist approach, everything could be defined in terms of three functions. At the other extreme you would have the functx approach, a thousand functions to do everything you could ever imagine, but where it’s quicker to write the function yourself than to find it in the library.

Michael Kay
Saxonica

Thanks,
Wouter
I would think both of these could be implemented as user-defined functions but it’s hard to know without seeing a specification: saying you want a function called array:index-of() is not very informative unless you explain exactly what you want the function to do.
If it’s to behave like fn:index-of() then you can write it as
array:index-of($array, $value) {
(1 to array:size($array))[ $array(.) = $value ]
}
which is hardly a great hardship to write as a user-defined function.
Michael Kay
Saxonica

Post by W.S. Hager
Hello,
- the lack of array:index-of()
- the lack of the iterator index in arrayfor-each and related higher-order functions
Perhaps someone of the workgroup is available to discuss those cases.
Thanks,
Wouter
--
W.S. Hager
Lagua Web Solutions
http://lagua.nl <http://lagua.nl/>
--
W.S. Hager
Lagua Web Solutions
http://lagua.nl <http://lagua.nl/>
_______________________________________________
http://x-query.com/mailman/listinfo/talk <http://x-query.com/mailman/listinfo/talk>

--
W.S. Hager
Lagua Web Solutions
http://lagua.nl <http://lagua.nl/>

[W.S. Hager]

On the whole I agree, and I respect the current status quo of the
specification. However, I expect more changes will follow from actually
working with it. IMHO the current distinction between sequences and arrays
could eventually be abolished.

Post by W.S. Hager
Agreed, it could be implemented as a user-defined function (although this
particular solution currently throws an error in eXist). However, what
bothers me is that fn:index-of(1,2,[3,4], 3) may lead to unexpected
results, because the array is flattened. I get the impression that
array-specific semantics are sacrificed here, where in other cases they
aren't, and the dividing line is still unclear me.
Arrays will give unexpected results, full stop. We spent two years trying
to find a design that didn’t have unexpected results, and we failed. Start
with the fact that $A[1] returns the whole array, and that you can’t
iterate over arrays with FLWOR expressions. Arrays are grafted on to the
data model as an afterthought, and it shows right through. That’s not for
want of trying: we were running out of names for all the different ideas we
rejected as unworkable.
The choice of functions in the library is inevitably arbitrary. I think we
found that if you wanted a completely minimalist approach, everything could
be defined in terms of three functions. At the other extreme you would have
the functx approach, a thousand functions to do everything you could ever
imagine, but where it’s quicker to write the function yourself than to find
it in the library.
Michael Kay
Saxonica
Thanks,
Wouter

Post by Michael Kay
I would think both of these could be implemented as user-defined
functions but it’s hard to know without seeing a specification: saying you
want a function called array:index-of() is not very informative unless you
explain exactly what you want the function to do.
If it’s to behave like fn:index-of() then you can write it as
array:index-of($array, $value) {
(1 to array:size($array))[ $array(.) = $value ]
}
which is hardly a great hardship to write as a user-defined function.
Michael Kay
Saxonica
Hello,
I've been working with the recent xquery 3.1 implementation in the
develop branch eXist-db. I encountered some cases that were quite hard to
- the lack of array:index-of()
- the lack of the iterator index in arrayfor-each and related
higher-order functions
Perhaps someone of the workgroup is available to discuss those cases.
Thanks,
Wouter
--
W.S. Hager
Lagua Web Solutions
http://lagua.nl
--
W.S. Hager
Lagua Web Solutions
http://lagua.nl
_______________________________________________
http://x-query.com/mailman/listinfo/talk

--
W.S. Hager
Lagua Web Solutions
http://lagua.nl

[W.S. Hager]

Ignore my last sentence, I don't want to make this claim.

Post by W.S. Hager
On the whole I agree, and I respect the current status quo of the
specification. However, I expect more changes will follow from actually
working with it. IMHO the current distinction between sequences and arrays
could eventually be abolished.

Post by W.S. Hager
Agreed, it could be implemented as a user-defined function (although this
particular solution currently throws an error in eXist). However, what
bothers me is that fn:index-of(1,2,[3,4], 3) may lead to unexpected
results, because the array is flattened. I get the impression that
array-specific semantics are sacrificed here, where in other cases they
aren't, and the dividing line is still unclear me.
Arrays will give unexpected results, full stop. We spent two years trying
to find a design that didn’t have unexpected results, and we failed. Start
with the fact that $A[1] returns the whole array, and that you can’t
iterate over arrays with FLWOR expressions. Arrays are grafted on to the
data model as an afterthought, and it shows right through. That’s not for
want of trying: we were running out of names for all the different ideas we
rejected as unworkable.
The choice of functions in the library is inevitably arbitrary. I think
we found that if you wanted a completely minimalist approach, everything
could be defined in terms of three functions. At the other extreme you
would have the functx approach, a thousand functions to do everything you
could ever imagine, but where it’s quicker to write the function yourself
than to find it in the library.
Michael Kay
Saxonica
Thanks,
Wouter

Post by Michael Kay
I would think both of these could be implemented as user-defined
functions but it’s hard to know without seeing a specification: saying you
want a function called array:index-of() is not very informative unless you
explain exactly what you want the function to do.
If it’s to behave like fn:index-of() then you can write it as
array:index-of($array, $value) {
(1 to array:size($array))[ $array(.) = $value ]
}
which is hardly a great hardship to write as a user-defined function.
Michael Kay
Saxonica
Hello,
I've been working with the recent xquery 3.1 implementation in the
develop branch eXist-db. I encountered some cases that were quite hard to
- the lack of array:index-of()
- the lack of the iterator index in arrayfor-each and related higher-order functions
Perhaps someone of the workgroup is available to discuss those cases.
Thanks,
Wouter
--
W.S. Hager
Lagua Web Solutions
http://lagua.nl
--
W.S. Hager
Lagua Web Solutions
http://lagua.nl
_______________________________________________
http://x-query.com/mailman/listinfo/talk

--
W.S. Hager
Lagua Web Solutions
http://lagua.nl

--
W.S. Hager
Lagua Web Solutions
http://lagua.nl

[Michael Kay]

IMHO the current distinction between sequences and arrays could eventually be abolished.
Not without dramatic incompatibilities.

The core problem is the equivalence of a singleton sequence and an item. Which is a great benefit in the XML arena, because you don’t have to worry about whether /book/author is returning a sequence or an item. But you can’t do nested sequences/arrays under this model, because if you allow nesting then you need to distinguish [[a]] from [a]. So we have arrays that allow nesting, and sequences where singletons are the same as items, and the two models are irreconcilable.

Michael Kay
Saxonica


_______________________________________________
***@x-query.com
http://x-query.com/mailman/listinfo/tal

[W.S. Hager]

Indeed. The only thing I'll add is that by adding the array feature you
kind of opened Pandora's box. As for me, I'm happy you did, because the
gain is obvious to me. How this will affect future specs I don't want to
hint at, but I'm quite curious.

As for my second case, it doesn't seem like a major change. When iterating
over an array with array:for-each you loose track of the iteration count.
I'm not sure if there's even a workaround, multi-dimensional arrays
considered. Would it be possible to (optionally) provide the iterator index
as the second parameter of the function?

Thanks.

Post by Michael Kay
IMHO the current distinction between sequences and arrays could eventually be abolished.
Not without dramatic incompatibilities.
The core problem is the equivalence of a singleton sequence and an item.
Which is a great benefit in the XML arena, because you don’t have to worry
about whether /book/author is returning a sequence or an item. But you
can’t do nested sequences/arrays under this model, because if you allow
nesting then you need to distinguish [[a]] from [a]. So we have arrays that
allow nesting, and sequences where singletons are the same as items, and
the two models are irreconcilable.
Michael Kay
Saxonica

[Christian Grün]

On the whole I agree, and I respect the current status quo of the specification. However, I expect more changes will follow from actually working with it. IMHO the current distinction between sequences and arrays could eventually be abolished.

While I haven't actively participated in the specification of arrays
in the XML Working Group, I have been following it quite actively.
Various impressive solutions were proposed, pretty soon it got more
than obvious that there is no chance to specify arrays in any way that
is completely consistent and intuitive. From the very beginning,
XQuery was designed to efficiently handle flattened sequences, and
this concept is completely different to what can be done with arrays.
The resulting solution for arrays will not be able to meet all
expectations, but I can clearly say I am pretty impressed with it.

Post by W.S. Hager
Ignore my last sentence, I don't want to make this claim.

Too late ;)

Post by W.S. Hager
Agreed, it could be implemented as a user-defined function (although this particular solution currently throws an error in eXist). However, what bothers me is that fn:index-of(1,2,[3,4], 3) may lead to unexpected results, because the array is flattened. I get the impression that array-specific semantics are sacrificed here, where in other cases they aren't, and the dividing line is still unclear me.
Arrays will give unexpected results, full stop. We spent two years trying to find a design that didn’t have unexpected results, and we failed. Start with the fact that $A[1] returns the whole array, and that you can’t iterate over arrays with FLWOR expressions. Arrays are grafted on to the data model as an afterthought, and it shows right through. That’s not for want of trying: we were running out of names for all the different ideas we rejected as unworkable.
The choice of functions in the library is inevitably arbitrary. I think we found that if you wanted a completely minimalist approach, everything could be defined in terms of three functions. At the other extreme you would have the functx approach, a thousand functions to do everything you could ever imagine, but where it’s quicker to write the function yourself than to find it in the library.
Michael Kay
Saxonica
Thanks,
Wouter

I would think both of these could be implemented as user-defined functions but it’s hard to know without seeing a specification: saying you want a function called array:index-of() is not very informative unless you explain exactly what you want the function to do.
If it’s to behave like fn:index-of() then you can write it as
array:index-of($array, $value) {
(1 to array:size($array))[ $array(.) = $value ]
}
which is hardly a great hardship to write as a user-defined function.
Michael Kay
Saxonica
Hello,
- the lack of array:index-of()
- the lack of the iterator index in arrayfor-each and related higher-order functions
Perhaps someone of the workgroup is available to discuss those cases.
Thanks,
Wouter
--
W.S. Hager
Lagua Web Solutions
http://lagua.nl
--
W.S. Hager
Lagua Web Solutions
http://lagua.nl
_______________________________________________
http://x-query.com/mailman/listinfo/talk

--
W.S. Hager
Lagua Web Solutions
http://lagua.nl

--
W.S. Hager
Lagua Web Solutions
http://lagua.nl
_______________________________________________
http://x-query.com/mailman/listinfo/talk

_______________________________________________
***@x-query.com
http://x-query.com/mailman/l

[W.S. Hager]

Hi Christian,

Post by Christian Grün
Too late ;)

Heh. I should have thought before posting, as it was merely a vague
intuition. The problem is of course backwards compatibility, as Michael
mentioned.

As an aside, does anyone know what the formal definition of sequences is,
where it came from, who introduced it into xquery?

Thanks.

[G. Ken Holman]

Post by W.S. Hager
As an aside, does anyone know what the formal definition of
sequences is, where it came from, who introduced it into xquery?

It is in XPath:

http://www.w3.org/TR/xpath-31/#id-sequence-expressions

http://www.w3.org/TR/xpath-31/#id-sequencetype-syntax

I hope this helps.

. . . . . . Ken


--
Check our site for free XML, XSLT, XSL-FO and UBL developer resources |
Free 5-hour lecture: http://www.CraneSoftwrights.com/links/video.htm |
Crane Softwrights Ltd. http://www.CraneSoftwrights.com/q/ |
G. Ken Holman mailto:***@CraneSoftwrights.com |
Google+ profile: http://plus.google.com/+GKenHolman-Crane/about |
Legal business disclaimers: http://www.CraneSoftwrights.com/legal |


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

_______________________________________________
***@x-query.com
http://x-query.com/mailman/listinfo/talk

[W.S. Hager]

Sorry, what I meant is: how did sequences come into XPath? Was it borrowed
from another system or did it appear first in XPath?

Post by G. Ken Holman

Post by W.S. Hager
As an aside, does anyone know what the formal definition of sequences is,
where it came from, who introduced it into xquery?

http://www.w3.org/TR/xpath-31/#id-sequence-expressions
http://www.w3.org/TR/xpath-31/#id-sequencetype-syntax
I hope this helps.
. . . . . . Ken
--
Check our site for free XML, XSLT, XSL-FO and UBL developer resources |
Free 5-hour lecture: http://www.CraneSoftwrights.com/links/video.htm |
Crane Softwrights Ltd. http://www.CraneSoftwrights.com/q/ |
Google+ profile: http://plus.google.com/+GKenHolman-Crane/about |
Legal business disclaimers: http://www.CraneSoftwrights.com/legal |
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

[David Carlisle]

Post by W.S. Hager
Sorry, what I meant is: how did sequences come into XPath? Was it
borrowed from another system or did it appear first in XPath?

It's a modification of the node set datatype introduced in xpath 1
(which didn't have sequences) Xpath 1 didn't have a type corresponding
to a node (or item) only node set, so treating a single item as the same
as a set of size 1 was more or less a requirement (and a very elegant
ruse:-)

David

________________________________


The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is:

Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.



This e-mail has been scanned for all viruses by Microsoft Office 365.

[W.S. Hager]

Indeed! Thanks David.

Post by David Carlisle

Post by W.S. Hager
Sorry, what I meant is: how did sequences come into XPath? Was it
borrowed from another system or did it appear first in XPath?

It's a modification of the node set datatype introduced in xpath 1
(which didn't have sequences) Xpath 1 didn't have a type corresponding
to a node (or item) only node set, so treating a single item as the same
as a set of size 1 was more or less a requirement (and a very elegant
ruse:-)
David
________________________________
The Numerical Algorithms Group Ltd is a company registered in England and
Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.
This e-mail has been scanned for all viruses by Microsoft Office 365.
________________________________
_______________________________________________
http://x-query.com/mailman/listinfo/talk

[daniela florescu]

David, Ken…

You know the XPath/XSLT side of the story.

I know the OTHER side: the XML Query Language Working Group side of the story
(and the two haven’t been integrated until much later..)

For a simple path expression sequences might have come natural.

For a FULL QUERY LANGUAGE, with nested queries, sorts, groupbys etc. this wasn’t a “natural” or “simple” decision AT ALL.

We pondered over this decision for about two years …..

…. and this was BEFORE the XML Query Working Group decide to use XPath for navigation.

Best
Dana

Post by David Carlisle

Post by W.S. Hager
Sorry, what I meant is: how did sequences come into XPath? Was it
borrowed from another system or did it appear first in XPath?

It's a modification of the node set datatype introduced in xpath 1
(which didn't have sequences) Xpath 1 didn't have a type corresponding
to a node (or item) only node set, so treating a single item as the same
as a set of size 1 was more or less a requirement (and a very elegant
ruse:-)
David
________________________________
Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.
This e-mail has been scanned for all viruses by Microsoft Office 365.
________________________________
_______________________________________________
http://x-query.com/mailman/listinfo/talk

_______________________________________________
***@x-query.com
http://x-query.com/mailman/listi

[David Carlisle]

Post by daniela florescu
David, Ken…
You know the XPath/XSLT side of the story.
I know the OTHER side: the XML Query Language Working Group side of the story

Yes I know that side of the story too (I think I read all the xquery
mailing list discussion, and implemented xquery 1 over XSLT, as you may
recall I think I was the first person to submit test results for an
Xquery 1 implementation to the XQ test suite:-)

Post by daniela florescu
(and the two haven’t been integrated until much later..)

Which was of course a major failing of the original Xquery proposals.
It was staggering that an W3C XML query language should _not_ start from
that base. Fortunately It was redrafted to sit over Xpath.
XQuery 1 was basically (and should have been defined as) a non-xml
syntax for a simplified subset of XSLT.


David,

________________________________


The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is:

Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.



This e-mail has been scanned for all viruses by Microsoft Office 365.

________________________________

_______________________________________________
***@x-query.com
http://x-que

[daniela florescu]

Post by David Carlisle

Post by daniela florescu
(and the two haven’t been integrated until much later..)

Which was of course a major failing of the original Xquery proposals.
It was staggering that an W3C XML query language should _not_ start from
that base. Fortunately It was redrafted to sit over Xpath.
XQuery 1 was basically (and should have been defined as) a non-xml
syntax for a simplified subset of XSLT.

This is just Yet-Another-Example of how hard it is to integrate two communities,
with two different backgrounds, and very strong beliefs.

I remember the first couple of “joint” meetings when we were almost ready to annihilated each other ….
It is funny in retrospect, because lost of silly things were said on both sides …:-) i remember like it was yesterday…:-)

I am surprised that the integration worked as well as it did in the end, and we both ended up learning from
each other ….

(even if the fact that I “learned” XML doesn’t mean AT ALL that I LIKE it , even after 15 years ...! :-)

Best regards
Dana






_______________________________________________
***@x-q

[daniela florescu]

Post by David Carlisle
Which was of course a major failing of the original Xquery proposals.
It was staggering that an W3C XML query language should _not_ start from
that base. Fortunately It was redrafted to sit over Xpath.
XQuery 1 was basically (and should have been defined as) a non-xml
syntax for a simplified subset of XSLT.

BTW, David… it’s funny after 15 years… -)

If the XSLT WG wanted a simple non-xml syntax for XSLT, they should have done it themselves…..why would this
have been OUR problem !?

What the XML QUERY Working Group wanted something COMPLETELY different, aka, a QUERY LANGUAGE,
out of which XSLT isn’t one …. that’s all.

Fun to see that those arguments don’t die even after 15 years :-)

I remember having those discussion on-line and off-line with James Clark… like a decade and a half ago !?? :-)

Actually, the first running implementation of the integration of XQuery and XPath parser was written by me and James
(both bitching about the “features” in other’s side..:-)

But overall, I think XSLT and XQuery ended up integrated pretty nicely, so it was worth the effort.

Best regards
Dana





_______________________________________________
ta

[W.S. Hager]

That should provide some positive perspectives for integrating with the
web... wait, did I just get off-topic? Oops? No. I write a great deal of
javascript, and this is actually why I would like my wishlist to be
considered. Functions like array:index-of and array:for-each (called map in
many more languages) feel off to me in xquery because of their resemblance
to javascript, but with slightly different semantics. Since this pertains
to "imperative" constructs, you may consider converging more towards
javascript, which was the reason for the 3.1 spec in the first place, if
I'm not mistaken. As an added advantage it would less surprise programmers
coming from javascript, I think.

Post by David Carlisle
Which was of course a major failing of the original Xquery proposals.
It was staggering that an W3C XML query language should _not_ start from
that base. Fortunately It was redrafted to sit over Xpath.
XQuery 1 was basically (and should have been defined as) a non-xml
syntax for a simplified subset of XSLT.

BTW, David
 it’s funny after 15 years
 -)
If the XSLT WG wanted a simple non-xml syntax for XSLT, they should have
done it themselves
..why would this
have been OUR problem !?
What the XML QUERY Working Group wanted something COMPLETELY different,
aka, a QUERY LANGUAGE,
out of which XSLT isn’t one 
. that’s all.
Fun to see that those arguments don’t die even after 15 years :-)
I remember having those discussion on-line and off-line with James Clark

like a decade and a half ago !?? :-)
Actually, the first running implementation of the integration of XQuery
and XPath parser was written by me and James
(both bitching about the “features” in other’s side..:-)
But overall, I think XSLT and XQuery ended up integrated pretty nicely, so
it was worth the effort.
Best regards
Dana
_______________________________________________
http://x-query.com/mailman/listinfo/talk

[W.S. Hager]

I meant *the lack of* array:index-of(), obviously.

Post by W.S. Hager
That should provide some positive perspectives for integrating with the
web... wait, did I just get off-topic? Oops? No. I write a great deal of
javascript, and this is actually why I would like my wishlist to be
considered. Functions like array:index-of and array:for-each (called map in
many more languages) feel off to me in xquery because of their resemblance
to javascript, but with slightly different semantics. Since this pertains
to "imperative" constructs, you may consider converging more towards
javascript, which was the reason for the 3.1 spec in the first place, if
I'm not mistaken. As an added advantage it would less surprise programmers
coming from javascript, I think.

Post by David Carlisle
Which was of course a major failing of the original Xquery proposals.
It was staggering that an W3C XML query language should _not_ start from
that base. Fortunately It was redrafted to sit over Xpath.
XQuery 1 was basically (and should have been defined as) a non-xml
syntax for a simplified subset of XSLT.

BTW, David
 it’s funny after 15 years
 -)
If the XSLT WG wanted a simple non-xml syntax for XSLT, they should have
done it themselves
..why would this
have been OUR problem !?
What the XML QUERY Working Group wanted something COMPLETELY different,
aka, a QUERY LANGUAGE,
out of which XSLT isn’t one 
. that’s all.
Fun to see that those arguments don’t die even after 15 years :-)
I remember having those discussion on-line and off-line with James Clark

like a decade and a half ago !?? :-)
Actually, the first running implementation of the integration of XQuery
and XPath parser was written by me and James
(both bitching about the “features” in other’s side..:-)
But overall, I think XSLT and XQuery ended up integrated pretty nicely,
so it was worth the effort.
Best regards
Dana
_______________________________________________
http://x-query.com/mailman/listinfo/talk

--
W.S. Hager
Lagua Web Solutions
http://lagua.nl

[daniela florescu]

Hi Wouter,

Functions like array:index-of and array:for-each (called map in many more languages) feel off to me in xquery because of their resemblance to javascript, but with slightly different semantics.

See my original complaints about a month ago about the design of XQuery 3.1, which was done
as if JSON and Javascript never existed…..and the one you bring up is only ONE kind of inconsistency.

Three years ago when I was bringing this kind of inconsistencies to the attention of XQuery WG, and all
the troubles they will bring LATER if we add maps to XQuery while ignoring JSON, Sharon Adler who was
running the XSLT WG decided that it was a good idea to forbid me from the WG…… and forbid my phone
calls to the WG…..

Well. Water under the bridge now.

this is actually why I would like my wishlist to be considered.

The important question for you is : you would like your opinion to be considered by WHO !??

Is the XQuery WG the right forum ?

I am not sure, as their mandate does not include proper JSON support.

But if not XQuery forum, then WHO should be concerned with this more “global” , smoother integration !??

The integration between XSLT and XQuery was in some sense simpler, because we were very focused
communities, with strict rules imposed by W3C, with a common goal: XML.

JSON and Javascript are not that….unfortunately.

XML and JSON communities are like water and oil….

So, who would like to be considered BY !??

(I wish I knew the answer to that question …)

Best regards
Dana





_______________________________________________
***@x-query.com
http://x-query.com/mailman/listinfo/tal

[W.S. Hager]

Hi Dana,

Thanks for your elaborate response. It's the first time I post to this
list, so it's more of a trail by fire, and I expected nothing less. I can
only say that I rather address this community than javascript's, because I
expect it to be less sensitive to buzz, and more pliable, since the ink of
the specs is barely dry.

As to who in particular should consider my ideas, I don't know, I'm just
hoping for a discussion, because AFAICT this isn't set in stone yet.

Thanks,
Wouter

Post by daniela florescu
Hi Wouter,

Functions like array:index-of and array:for-each (called map in many

more languages) feel off to me in xquery because of their resemblance to
javascript, but with slightly different semantics.
See my original complaints about a month ago about the design of XQuery 3.1, which was done
as if JSON and Javascript never existed
..and the one you bring up is only
ONE kind of inconsistency.
Three years ago when I was bringing this kind of inconsistencies to the
attention of XQuery WG, and all
the troubles they will bring LATER if we add maps to XQuery while ignoring
JSON, Sharon Adler who was
running the XSLT WG decided that it was a good idea to forbid me from
the WG

 and forbid my phone
calls to the WG
..
Well. Water under the bridge now.

this is actually why I would like my wishlist to be considered.

The important question for you is : you would like your opinion to be considered by WHO !??
Is the XQuery WG the right forum ?
I am not sure, as their mandate does not include proper JSON support.
But if not XQuery forum, then WHO should be concerned with this more
“global” , smoother integration !??
The integration between XSLT and XQuery was in some sense simpler, because
we were very focused
communities, with strict rules imposed by W3C, with a common goal: XML.
JSON and Javascript are not that
.unfortunately.
XML and JSON communities are like water and oil
.
So, who would like to be considered BY !??
(I wish I knew the answer to that question 
)
Best regards
Dana

[W.S. Hager]

Perhaps I should underline that I don't find these "inconsistencies" very
problematic. It's not javascript, and the language has been spectacularly
enriched by these function types. I'm sure it'll be fine without the
conviences I suggested.

Thanks.

Post by W.S. Hager
Hi Dana,
Thanks for your elaborate response. It's the first time I post to this
list, so it's more of a trail by fire, and I expected nothing less. I can
only say that I rather address this community than javascript's, because I
expect it to be less sensitive to buzz, and more pliable, since the ink of
the specs is barely dry.
As to who in particular should consider my ideas, I don't know, I'm just
hoping for a discussion, because AFAICT this isn't set in stone yet.
Thanks,
Wouter

Post by daniela florescu
Hi Wouter,

Functions like array:index-of and array:for-each (called map in many

more languages) feel off to me in xquery because of their resemblance to
javascript, but with slightly different semantics.
See my original complaints about a month ago about the design of XQuery
3.1, which was done
as if JSON and Javascript never existed
..and the one you bring up is
only ONE kind of inconsistency.
Three years ago when I was bringing this kind of inconsistencies to the
attention of XQuery WG, and all
the troubles they will bring LATER if we add maps to XQuery while
ignoring JSON, Sharon Adler who was
running the XSLT WG decided that it was a good idea to forbid me from
the WG

 and forbid my phone
calls to the WG
..
Well. Water under the bridge now.

this is actually why I would like my wishlist to be considered.

The important question for you is : you would like your opinion to be
considered by WHO !??
Is the XQuery WG the right forum ?
I am not sure, as their mandate does not include proper JSON support.
But if not XQuery forum, then WHO should be concerned with this more
“global” , smoother integration !??
The integration between XSLT and XQuery was in some sense simpler,
because we were very focused
communities, with strict rules imposed by W3C, with a common goal: XML.
JSON and Javascript are not that
.unfortunately.
XML and JSON communities are like water and oil
.
So, who would like to be considered BY !??
(I wish I knew the answer to that question 
)
Best regards
Dana

--
W.S. Hager
Lagua Web Solutions
http://lagua.nl

[daniela florescu]

Lucky you, I would say.

Because for the people who need to use XQuery and JSON/Javascript in the same time
those inconsistencies will be such a constant source of frustration and a constant source of errors 
.

Consequences:
- chances of XQuery (or XQuery ideas) being used by the JSON community go down significantly
- billions of dollars due to loss of productivity overall
- probably very tight restriction of the user population of XQuery.

Just saying
 if this doesn’t bother you, consider yourself lucky.

Best regards
Dana

That should provide some positive perspectives for integrating with the web... wait, did I just get off-topic? Oops? No. I write a great deal of javascript, and this is actually why I would like my wishlist to be considered. Functions like array:index-of and array:for-each (called map in many more languages) feel off to me in xquery because of their resemblance to javascript, but with slightly different semantics. Since this pertains to "imperative" constructs, you may consider converging more towards javascript, which was the reason for the 3.1 spec in the first place, if I'm not mistaken. As an added advantage it would less surprise programmers coming from javascript, I think.

Post by David Carlisle
Which was of course a major failing of the original Xquery proposals.
It was staggering that an W3C XML query language should _not_ start from
that base. Fortunately It was redrafted to sit over Xpath.
XQuery 1 was basically (and should have been defined as) a non-xml
syntax for a simplified subset of XSLT.

BTW, David
 it’s funny after 15 years
 -)
If the XSLT WG wanted a simple non-xml syntax for XSLT, they should have done it themselves
..why would this
have been OUR problem !?
What the XML QUERY Working Group wanted something COMPLETELY different, aka, a QUERY LANGUAGE,
out of which XSLT isn’t one 
. that’s all.
Fun to see that those arguments don’t die even after 15 years :-)
I remember having those discussion on-line and off-line with James Clark
 like a decade and a half ago !?? :-)
Actually, the first running implementation of the integration of XQuery and XPath parser was written by me and James
(both bitching about the “features” in other’s side..:-)
But overall, I think XSLT and XQuery ended up integrated pretty nicely, so it was worth the effort.
Best regards
Dana
_______________________________________________
http://x-query.com/mailman/listinfo/talk <http://x-query.com/mailman/listinfo/talk>
--
W.S. Hager
Lagua Web Solutions
http://lagua.nl <http://lagua.nl/>
_______________________________________________
http://x-query.com/mailman/listinfo/talk

[daniela florescu]

Post by David Carlisle
Yes I know that side of the story too (I think I read all the xquery
mailing list discussion,

Dear David,

you read the mailing lists from W3C 1999-2000-2001. That’s great.

But I WAS there.

My XML query language (XML-QL ) — used by AT&T in a large number of applications--
http://www.w3.org/TR/NOTE-xml-ql/
……. triggered the W3C XML Query Languages Workshop,
http://www.w3.org/TandS/QL/QL98/
……..which in turn triggered the creation of the W3C XML Query WorkIng Group.
======



You know why I am replying those “historical” questions !?

Because I am THE ONLY ONE from that time who still pays attention to this mailing list.
(don’t ask me why, because you’ll have along answer :-)

And I am the ONLY ONE who still knows the stories (and the motivations, visible in the minutes or not, for many decisions..).

Some of those stories are technically interesting.

Whoever wants to avoid repeating history ….. has to learn history.

Best regards
Dana


_______________________________________________
***@x-query.com
http://x-query.com/mailman/lis

[daniela florescu]

Sorry, what I meant is: how did sequences come into XPath? Was it borrowed from another system or did it appear first in XPath?

Hi Wouter,

languages that work on sequences there are plenty in programming languages, especially function programming languages: e..g. Lisp !?, ML !?
(head(), tail() ? :-)

But your question is about the history of XQuery. Here it is.

In the XQuery per se, the data model based on sequences appeared around 1999-2000, even before we started joint activity with the XSLT working group,
and even before XQuery decided to use XPath for navigation.

It was the decision of the entire working group, obviously.

The editors of the Data Model at that time — and they both did a huge contribution to the guidance and cleaning up the
opinions in the XQuery WG — were Mary Fernandez (ATT Research and Denise Draper (now at Microsoft).

But you have to understand that the composition at that time of the XQuery Working group was VERY different then it is now.

There were many people with a very strong functional languages background: Mary Fernandez, Phuil Wadler (of Haskell fame), Denise Draper.
Sequences are very normal to them because of Lisp.

There were many people with a database background: Don Chamberlin (of SQL fame), Jonathan Robie, Jim Melton, etc
For the database community iteration over sequences is the bread and butter of any database runtime (the famous iterator model,
see http://bnrg.cs.berkeley.edu/~adj/cs262/papers/graefe.pdf <http://bnrg.cs.berkeley.edu/~adj/cs262/papers/graefe.pdf>), so again this came naturally to them.

And then there were people with one foot in the functional community and one foot in the database community, like me and Jerome Simeon
(IBM) : we both implemented OQL as part of our PhDs - the object oriented query language https://en.wikipedia.org/wiki/Object_Query_Language <https://en.wikipedia.org/wiki/Object_Query_Language>)

OQL is a functional query language, which greatly influenced the design of XQuery.

Both me and Jerome learned from implementing OQL that the basic type system of OQL was WAY too complicated: it had sets, bags and lists.

Optimizing that thing was a nightmare. So was understanding the semantics.

So both of us pushed for the simplification of the data model.

The single common denominator for sets, bags and lists are: lists. With lists you can implement the others but not the other way around.

=========

So, here you got the sequences.



I think the other decision : make a single item behave the same as a sequence with one item came after we started working with Path, as it was
already embedded in the XPath semantics.

Hope that helps,
Dana

[daniela florescu]

Post by daniela florescu
And then there were people with one foot in the functional community and one foot in the database community, like me and Jerome Simeon
(IBM) : we both implemented OQL as part of our PhDs - the object oriented query language https://en.wikipedia.org/wiki/Object_Query_Language <https://en.wikipedia.org/wiki/Object_Query_Language>)

Oh
and how can I forget, stupid me !? :-)

In the bunch with me and Jerome, all three influenced by both functional programming AND databases, was also Michael Rys (Microsoft).

He was also fundamental in this decision, and many other afterwards.

HTH,
Dana

[W.S. Hager]

Hi Dana,

Great stuff, thank you for this brief history of xquery! It's good to
understand from your story that arrays don't add as much complexity as
there could have been with sets, bags and lists. However, that said the
array spec does seem a bit like a mixed paradigm solution. Let's just say
it's a mixed blessing, as IMO neither functional nor imperative typesystems
provide all the answers.

Wouter

Post by daniela florescu
And then there were people with one foot in the functional community and
one foot in the database community, like me and Jerome Simeon
(IBM) : we both implemented OQL as part of our PhDs - the object oriented
query language https://en.wikipedia.org/wiki/Object_Query_Language)
Oh
and how can I forget, stupid me !? :-)
In the bunch with me and Jerome, all three influenced by both functional
programming AND databases, was also Michael Rys (Microsoft).
He was also fundamental in this decision, and many other afterwards.
HTH,
Dana

[daniela florescu]

Let's just say it's a mixed blessing, as IMO neither functional nor imperative typesystems provide all the answers.

I agree with you. It’s a compromise, and honestly, I cannot imagine a better way of doing things
..maybe I am just not smart enough...

If you make it 100% functional it is very hard to program in.

If you make it 100% imperative you kill optimization.

If you make it predicate-based (as SQL) you don’t have enough expressive power.

So 
..

Dana

[Per Bothner]

Post by daniela florescu
languages that work on sequences there are plenty in programming languages, especially function programming languages: e..g. Lisp !?, ML !?
(head(), tail() ? :-)

To avoid confusion: None of these have sequences in the XQuery/XPath sense, i.e. where a singleton sequence
and an item are equivalent.

[Adam Retter]

Hi Wouter,

If you want to directly contact the working group I would suggest
filing a feature-request via Bugzilla -
http://www.w3.org/XML/2005/04/qt-bugzilla. If you can't reach that you
could try the public-qt-***@w3.org mailing list.

However, keep in mind that this would most likely now be aimed at an
XQuery 3.2, so I guess we would need to accumulate a few feature
requests/bugfixes yet to even get that off the ground.

Personally I would also like to see a ternary operator, but I haven't
mentioned it until now ;-)

Post by W.S. Hager
Hello,
I've been working with the recent xquery 3.1 implementation in the develop
branch eXist-db. I encountered some cases that were quite hard to work
- the lack of array:index-of()
- the lack of the iterator index in arrayfor-each and related higher-order
functions
Perhaps someone of the workgroup is available to discuss those cases.
Thanks,
Wouter
--
W.S. Hager
Lagua Web Solutions
http://lagua.nl
--
W.S. Hager
Lagua Web Solutions
http://lagua.nl
_______________________________________________
http://x-query.com/mailman/listinfo/talk

[Christian Grün]

Post by Adam Retter
Personally I would also like to see a ternary operator, but I haven't
mentioned it until now ;-)

+1 ;) But if I remember right, it has already been motivated and
discussed in the group before.

Talking about conditions: An if expression without 'else' branch would
often be nice as well (if not present, an empty sequence could be
returned).

Post by Adam Retter

Post by W.S. Hager
Hello,
I've been working with the recent xquery 3.1 implementation in the develop
branch eXist-db. I encountered some cases that were quite hard to work
- the lack of array:index-of()
- the lack of the iterator index in arrayfor-each and related higher-order
functions
Perhaps someone of the workgroup is available to discuss those cases.
Thanks,
Wouter
--
W.S. Hager
Lagua Web Solutions
http://lagua.nl
--
W.S. Hager
Lagua Web Solutions
http://lagua.nl
_______________________________________________
http://x-query.com/mailman/listinfo/talk

--
Adam Retter
skype: adam.retter
tweet: adamretter
http://www.adamretter.org.uk
_______________________________________________
http://x-query.com/mailman/listinfo/talk

_______________________________________________
***@x-query.com
http://x-query.com/mailman/listinfo/talk

[W.S. Hager]

Hmm, I'm not so sure. The if/else clause is pretty short as it is, and
semantically more clear. But it's another discussion altogether.

For me the paint points remain in array support/semantics. I thought it
best to let it rest for a while and see if the workarounds proof to be
feasible. I think I was too eager to address this in the first place.

Regards,
Wouter

Post by Christian Grün

Post by Adam Retter
Personally I would also like to see a ternary operator, but I haven't
mentioned it until now ;-)

+1 ;) But if I remember right, it has already been motivated and
discussed in the group before.
Talking about conditions: An if expression without 'else' branch would
often be nice as well (if not present, an empty sequence could be
returned).

Post by Adam Retter

Post by W.S. Hager
Hello,
I've been working with the recent xquery 3.1 implementation in the

develop

Post by Adam Retter

Post by W.S. Hager
branch eXist-db. I encountered some cases that were quite hard to work
- the lack of array:index-of()
- the lack of the iterator index in arrayfor-each and related

higher-order

Post by Adam Retter

Post by W.S. Hager
functions
Perhaps someone of the workgroup is available to discuss those cases.
Thanks,
Wouter
--
W.S. Hager
Lagua Web Solutions
http://lagua.nl
--
W.S. Hager
Lagua Web Solutions
http://lagua.nl
_______________________________________________
http://x-query.com/mailman/listinfo/talk

--
Adam Retter
skype: adam.retter
tweet: adamretter
http://www.adamretter.org.uk
_______________________________________________
http://x-query.com/mailman/listinfo/talk

[W.S. Hager]

One more consideration: function calls seem to be more expensive than
inline expressions. And then there's that baggage of a custom library...

Post by W.S. Hager
Hmm, I'm not so sure. The if/else clause is pretty short as it is, and
semantically more clear. But it's another discussion altogether.
For me the paint points remain in array support/semantics. I thought it
best to let it rest for a while and see if the workarounds proof to be
feasible. I think I was too eager to address this in the first place.
Regards,
Wouter

Post by Christian Grün

Post by Adam Retter
Personally I would also like to see a ternary operator, but I haven't
mentioned it until now ;-)

+1 ;) But if I remember right, it has already been motivated and
discussed in the group before.
Talking about conditions: An if expression without 'else' branch would
often be nice as well (if not present, an empty sequence could be
returned).

Post by Adam Retter

Post by W.S. Hager
Hello,
I've been working with the recent xquery 3.1 implementation in the

develop

Post by Adam Retter

Post by W.S. Hager
branch eXist-db. I encountered some cases that were quite hard to work
- the lack of array:index-of()
- the lack of the iterator index in arrayfor-each and related

higher-order

Post by Adam Retter

Post by W.S. Hager
functions
Perhaps someone of the workgroup is available to discuss those cases.
Thanks,
Wouter
--
W.S. Hager
Lagua Web Solutions
http://lagua.nl
--
W.S. Hager
Lagua Web Solutions
http://lagua.nl
_______________________________________________
http://x-query.com/mailman/listinfo/talk

--
Adam Retter
skype: adam.retter
tweet: adamretter
http://www.adamretter.org.uk
_______________________________________________
http://x-query.com/mailman/listinfo/talk

--
W.S. Hager
Lagua Web Solutions
http://lagua.nl

[Christian Grün]

One more consideration: function calls seem to be more expensive than inline
expressions. And then there's that baggage of a custom library...

Doesn't that depend on the implementation? Functions may e.g. be
inlined and further compiled, and the evaluated expression may differ
a lot from the original expression.

Post by W.S. Hager
Hmm, I'm not so sure. The if/else clause is pretty short as it is, and
semantically more clear. But it's another discussion altogether.
For me the paint points remain in array support/semantics. I thought it
best to let it rest for a while and see if the workarounds proof to be
feasible. I think I was too eager to address this in the first place.
Regards,
Wouter

Post by Christian Grün

Post by Adam Retter
Personally I would also like to see a ternary operator, but I haven't
mentioned it until now ;-)

+1 ;) But if I remember right, it has already been motivated and
discussed in the group before.
Talking about conditions: An if expression without 'else' branch would
often be nice as well (if not present, an empty sequence could be
returned).

Post by Adam Retter

Post by W.S. Hager
Hello,
I've been working with the recent xquery 3.1 implementation in the develop
branch eXist-db. I encountered some cases that were quite hard to work
- the lack of array:index-of()
- the lack of the iterator index in arrayfor-each and related higher-order
functions
Perhaps someone of the workgroup is available to discuss those cases.
Thanks,
Wouter
--
W.S. Hager
Lagua Web Solutions
http://lagua.nl
--
W.S. Hager
Lagua Web Solutions
http://lagua.nl
_______________________________________________
http://x-query.com/mailman/listinfo/talk

--
Adam Retter
skype: adam.retter
tweet: adamretter
http://www.adamretter.org.uk
_______________________________________________
http://x-query.com/mailman/listinfo/talk

--
W.S. Hager
Lagua Web Solutions
http://lagua.nl

--
W.S. Hager
Lagua Web Solutions
http://lagua.nl

_______________________________________________
***@x-query.com
http://x-query.com/

[Adam Retter]

Post by Christian Grün

One more consideration: function calls seem to be more expensive than inline
expressions. And then there's that baggage of a custom library...

Doesn't that depend on the implementation? Functions may e.g. be
inlined and further compiled, and the evaluated expression may differ
a lot from the original expression.

Agreed. That is entirely down to the specific implementation.
Different implementations offer different optimisations (or not). For
example loop-unrolling, TCO, DCE, etc, etc. Function Inlining is just
another optimisation that an implementation could offer where
appropriate.

Post by Christian Grün

Post by W.S. Hager
Hmm, I'm not so sure. The if/else clause is pretty short as it is, and
semantically more clear. But it's another discussion altogether.
For me the paint points remain in array support/semantics. I thought it
best to let it rest for a while and see if the workarounds proof to be
feasible. I think I was too eager to address this in the first place.
Regards,
Wouter

Post by Christian Grün

Post by Adam Retter
Personally I would also like to see a ternary operator, but I haven't
mentioned it until now ;-)

+1 ;) But if I remember right, it has already been motivated and
discussed in the group before.
Talking about conditions: An if expression without 'else' branch would
often be nice as well (if not present, an empty sequence could be
returned).

Post by Adam Retter

Post by W.S. Hager
Hello,
I've been working with the recent xquery 3.1 implementation in the develop
branch eXist-db. I encountered some cases that were quite hard to work
- the lack of array:index-of()
- the lack of the iterator index in arrayfor-each and related higher-order
functions
Perhaps someone of the workgroup is available to discuss those cases.
Thanks,
Wouter
--
W.S. Hager
Lagua Web Solutions
http://lagua.nl
--
W.S. Hager
Lagua Web Solutions
http://lagua.nl
_______________________________________________
http://x-query.com/mailman/listinfo/talk

--
Adam Retter
skype: adam.retter
tweet: adamretter
http://www.adamretter.org.uk
_______________________________________________
http://x-query.com/mailman/listinfo/talk

--
W.S. Hager
Lagua Web Solutions
http://lagua.nl

--
W.S. Hager
Lagua Web Solutions
http://lagua.nl

[Michael Kay]

One more consideration: function calls seem to be more expensive than inline expressions.

Saxon and I’m sure other products will inline function calls when they consider it appropriate. Because XQuery is side-effect-free and has no polymorphism, this is a pretty straightforward optimization.

And then there's that baggage of a custom library...

I’m not sure what you’re referring to here.

Michael Kay
Saxonica
_______________________________________________
***@x-query.com
http:/

[W.S. Hager]

Sorry, I didn't mention I was thinking about the case where I would create
a library module instead of using inline functions.

Post by W.S. Hager

Post by W.S. Hager
One more consideration: function calls seem to be more expensive than

inline expressions.
Saxon and I’m sure other products will inline function calls when they
consider it appropriate. Because XQuery is side-effect-free and has no
polymorphism, this is a pretty straightforward optimization.

Post by W.S. Hager
And then there's that baggage of a custom library...

I’m not sure what you’re referring to here.
Michael Kay
Saxonica

[Adam Retter]

Your library module is still just functions, so they can also be
optimised and inlined. If they are written in XQuery then the XQuery
processor needs to support/offer that optimisation, if they are
written in Java (or other) as processor extensions then it is likely
that the Java compiler/JIT (or other) will perform that optimisation.

Sorry, I didn't mention I was thinking about the case where I would create a
library module instead of using inline functions.

Post by Michael Kay

Post by W.S. Hager
One more consideration: function calls seem to be more expensive than
inline expressions.

Saxon and I’m sure other products will inline function calls when they
consider it appropriate. Because XQuery is side-effect-free and has no
polymorphism, this is a pretty straightforward optimization.

Post by W.S. Hager
And then there's that baggage of a custom library...

I’m not sure what you’re referring to here.
Michael Kay
Saxonica

--
W.S. Hager
Lagua Web Solutions
http://lagua.nl

--
Adam Retter

skype: adam.retter
tweet: adamretter
http://www.adamretter.org.uk

_______________________________________________
***@x-query.com
h