DASL language comparison

[Julian Reschke]

Hi everybody.

I'm currently looking at what it takes to clean up the current draft
(see
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-latest.htm>)
so that it can be submitted to the RFC Editor for publication as
Experimental RFC -- it seems to me that would be the right step, there's
clearly not sufficient energy to fully complete the work, but there are
lots of implementations out there that would benefit from a stable spec.

Anyway, one of the issues we probably can't avoid fixing is the issue of
string comparisons, that is collation sequences.

In this case, two very similar approaches come to mind:

(1) Rely on XSLT collations
(<http://www.w3.org/TR/xquery-operators/#collations>), requiring support
for codepoint-by-codepoint
(<http://www.w3.org/2005/xpath-functions/collation/codepoint>), or

(2) Rely on
<http://www.ietf.org/internet-drafts/draft-newman-i18n-comparator-14.txt>.

Both give us roughly the same features, however (2) has the severe
drawback that it only defines the collation registry, but not an actual
collation we could require (we need at least a basic one that works for
non-ASCII characters).

Feedback appreciated,

Julian

[Jim Whitehead-2]

One of the original goals of DASL is to be able to create queries  
that easily translate to SQL. If you have a DASL interpreter of this  
type (as is the case with Catacomb), then the collation order is, to  
a large extent, outside the control of the DASL implementation. The  
collation order is controlled by the underlying SQL engine.

I imagine that if the DASL specification indicated a collation order  
that was inconsistent with the underlying query engine use by an  
implementation, the implementation would just ignore the specification.

- Jim

[Julian Reschke]

Jim Whitehead schrieb:
> One of the original goals of DASL is to be able to create queries that
> easily translate to SQL. If you have a DASL interpreter of this type (as
> is the case with Catacomb), then the collation order is, to a large
> extent, outside the control of the DASL implementation. The collation
> order is controlled by the underlying SQL engine.

Right. And even worse, you may even not be able to find out what the
collation is.

> I imagine that if the DASL specification indicated a collation order
> that was inconsistent with the underlying query engine use by an
> implementation, the implementation would just ignore the specification.

Right. I'm currently tempted to close this issue as WONTFIX for the
initial revision, and add an appendix discussing the issues and
potential approaches.

Best regards, Julian

[Jim Whitehead-2]

On Dec 18, 2006, at 9:52 AM, Julian Reschke wrote:

>
> Jim Whitehead schrieb:
>> One of the original goals of DASL is to be able to create queries  
>> that easily translate to SQL. If you have a DASL interpreter of  
>> this type (as is the case with Catacomb), then the collation order  
>> is, to a large extent, outside the control of the DASL  
>> implementation. The collation order is controlled by the  
>> underlying SQL engine.
>
> Right. And even worse, you may even not be able to find out what  
> the collation is.

I agree this is undesirable. OTOH, short of exposing a string  
identifying the underlying database and version (a security risk),  
I'm not sure how we could reliably expose this.

>
>> I imagine that if the DASL specification indicated a collation  
>> order that was inconsistent with the underlying query engine use  
>> by an implementation, the implementation would just ignore the  
>> specification.
>
> Right. I'm currently tempted to close this issue as WONTFIX for the  
> initial revision, and add an appendix discussing the issues and  
> potential approaches.

I'd love to hear a better solution, but I think what you are stating  
is realistic.

- Jim

[Julian Reschke]

Jim Whitehead schrieb:

>> Right. I'm currently tempted to close this issue as WONTFIX for the
>> initial revision, and add an appendix discussing the issues and
>> potential approaches.
>
> I'd love to hear a better solution, but I think what you are stating is
> realistic.

OK, see
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-latest.html#rfc.issue.language-comparison>,
in particular the summary at
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-latest.html#unresolved.issues.collations>:


B.1.  Collation Support

    Matching and sorting of textual data relies on collations.  With
    respect to WebDAV SEARCH, a combination of various design approaches
    could be used:

    o  Require server support for specific collations.

    o  Require that the server can advertise which collations it
       supports.

    o  Allow a client to select the collation to be used.

    In practice, the current implementations of WebDAV SEARCH usually
    rely on backends they do not control, and for which collation
    information may not be available.  To make things worse,
    implementations of the DAV:basicsearch grammar frequently need to
    combine data from multiple underlying stores (such as properties and
    full text content), and thus collation support may vary based on the
    operator or property.

    Another open issue is what collation formalism to support.  At the
    time of this writing, the two specifications below seem to provide
    the necessary framework and thus may be the base for future work on
    collation support in WebDAV SEARCH:

    1.  "Internet Application Protocol Collation Registry" (<http://
        www.ietf.org/internet-drafts/draft-newman-i18n-comparator-14>).

    2.  "XQuery 1.0 and XPath 2.0 Functions and Operators"
        (<http://www.w3.org/TR/xquery-operators/#collations>).






Best regards, Julian