RE: comment on issues in DASL draft: JW24d

I think this would be an interesting feature, but it seems to be extremely
hard to implement.

So assuming a query that

- the query specifies a language and
- be the text content of the property matches

The result will be:

1) true (match), if the property was stored with a matching xml:lang
property (where the language tag matching rules would have to apply)
2) undefined if the property was stored without xml:lang
3) false otherwise

On the other hand if

- the query doesn't specify a language

the result will be:

4) undefined (at least according to the current wording).


1) requires that the query engine actually knows how to match language
tags -- I'm not sure that everybody is willing to implement that.
2) is this desirable?
3) ok.
4) that seems to be wrong. If the query doesn't care, it should match,

Other problems:

- what is the language of a date-typed property?
- (sic!) where should xml:lang go into the query? There's no XML feature to
undefine an xml:lang which is in scope, but there may be cases where this is

On the other hand, if we drop this requirement, a client can still do a
query and then process the result set -- the property elements in the
response body will be reported with xml:lang (when persisted with language)

So I'd recommend to drop the feature. Defining string comparisons vs.
collation sequences is hard enough.

  -----Original Message-----
[]On Behalf Of Jim Davis
  Sent: Tuesday, May 28, 2002 2:10 AM
  Subject: comment on issues in DASL draft: JW24d

  EJW asked: Where does xml:lang go in a query?

  This is answered by text in 5.6.1 (regardless of how the issue in 5.6.1 is

   julian.reschke replied " What would be the *purpose* of putting xml:lang
into a query?"

  The purpose is to allow one to express queries more precisely, e.g. to
distinguish between the English word "hoop" (a circular object) and Dutch
"hoop" (hope).  Imagine a property that holds keywords for a resource.   See
4.4 in, and 2.12 in

Received on Tuesday, 28 May 2002 04:10:18 UTC