[Mulgara-general] firefox bug and server config

Gregg Reynolds dev at mobileink.com
Wed Sep 9 15:07:24 UTC 2009


On Wed, Sep 9, 2009 at 8:18 AM, Paul Gearon <gearon at ieee.org> wrote:

> >>
> > SPARQL's "ORDER BY" clause, using "<"; for semantics the SPARQL
> definition
> > refers to XQuery/XPath function "fn:compare", which supports multiple
> > collations.
>
> This function supports multiple collations, true, but if you look
> again you'll notice that SPARQL does not support it at all.
>

Hmm.  My reading of SPARQL is that it does require it; what am I missing?

Section 9.1:  "The "<"
operator<http://www.w3.org/TR/rdf-sparql-query/#op_lt>(see the
Operator
Mapping <http://www.w3.org/TR/rdf-sparql-query/#OperatorMapping> and 11.3.1
Operator Extensibility<http://www.w3.org/TR/rdf-sparql-query/#operatorExtensibility>)
defines the relative order of pairs of numerics, simple literals,
xsd:strings, xsd:booleans and xsd:dateTimes."

Section 11.13 says that "A < B" for xsd:strings means
"op:numeric-equal<http://www.w3.org/TR/xpath-functions/#func-numeric-equal>
(fn:compare <http://www.w3.org/TR/xpath-functions/#func-compare>(STR<http://www.w3.org/TR/rdf-sparql-query/#func-str>(A),
STR <http://www.w3.org/TR/rdf-sparql-query/#func-str>(B)), -1)"

Ok, I see, you're saying that (from XQuery/XPath 7.3.2):

fn:compare($comparand1 as xs:string?,
$comparand2 as xs:string?) as xs:integer?

is required but

fn:compare( $comparand1  as xs:string?,
$comparand2  as xs:string?,
$collation  as xs:string) as xs:integer?

is optional, correct?  Ok, but on the other hand, SPARQL says "The collation
for fn:compare is defined by
XPath<http://www.w3.org/TR/xpath-functions/#collations>",
which in turn says, well, a bunch of
stuff<http://www.w3.org/TR/xpath-functions/#collations>,
which could be read to mean fn:compare must(?) support both signatures.

To me it looks like the SPARQL definition is buggy on this point.  I guess
I'll submit an issue to the SPARQL2 folks.

I *did* notice that SPARQL leaves comparison between language tagged
> literals as "undefined", meaning that it *is* possible to use
>

Oh, yuck!  I mean I can see leaving the ordering of "church"@en and
"church"@es (Spanish?) undefined, but if they both have the same language
tag?  I guess the reasoning must be that one doesn't know if a literal is
supposed to represent a string or not, but it seems a little iffy.  Why
support a language tag at all then?  This looks like a major boo-boo; it
would mean one would have to always markup strings as rdf:XMLLiteral and
include an xml:lang attribute.  I think.


> collations here. So for instance, 'Strasse'@de and 'Straße'@de could
> compare equal, while 'Strasse' and 'Straße' differ.
>

Huge problem with SPARQL, imho.  Different implementations are apparently
free to order such strings according to whim, which means ORDER BY is
useless, since the client will have to sort anyway.  I think.
scope of anyone working on Mulgara at the moment. It wouldn't be so

> hard, if only I could find a library that would implement fn:compare.
>

I'm guessing that ICU is a pretty good bet, unless fn:compare collation
semantics deviate from Unicode.


Incidentally, this is a general request for anyone reading this.....
> if you know of anything that can do the range of XQuery/XPath
> functions then I'd love to hear from you. Specifically, I'm after
> something that provides an javax.xml.xpath.XPathFunctionResolver. At
> this point I'm even prepared to consider creating a plugin framework
> for commercial libraries. What I *can* tell you is that Saxon and
> Apache don't provide them. EXSLT has a lot of functions, but only
>

See also XML (XQuery) database implementations like
Xindice<http://xml.apache.org/xindice/>and
eXist <http://demo.exist-db.org/exist/index.xml>.

-gregg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mulgara.org/pipermail/mulgara-general/attachments/20090909/6a1609b6/attachment.htm>


More information about the Mulgara-general mailing list