Re: Questions/Comments on DASL

At 10:53 AM 10/12/99 -0700, Kevin Wiggen wrote: 
>
> I have read threw a number of the old posts, and I apologize if I am bringing
> up old things....
>  
> 1)  I agree there needs to be a way of getting next set, previous set for
> results.  I argue whether the protocol itself should help implement it (with
> query id's etc), but some functionality needs to be put in.


I think it would be fair to say that there is a lot of requests for this.  Do
you think this is a feature that is essential (that is, without is, DASL would
be unusable, or not worth using -- and if the latter, what would you use
instead) or only "desirable"?

>
> 2)  Dates.  The spec is silent on all date type of properties.  I am assuming
> that since RFC2518 states that creationdate is ISO8601 Date and Time profile,
> so dates in the query (where clause) must be in this format.


yes

>
> getlastmodified is a HTTP-date (never really understood why these where
> different),


For a definitive opinion, ask on the WebDAV list, but my best guess is that
HTTP date follows the format of the HTTP Date header for compatibility.  But
there are many complaints about that format, and ISO 8601 is prefered for all
date/time representations in the future.

>
>  and thus queries which contain this property must be in this format.  I also
> assume that a "LIKE" on a date will just do a simple conversion of the DATE
> to a String and then compare.  This is usually useless,


yes, a LIKE comparison would only make sense for strings. But can you explain
why you think this is usually useless?  For example, if you want all the dates
in October 1999 what's wrong like

date like "1999-10-*"

>
>  but nonetheless so are most conversions.  OR are we going to define a date
> format mask which we should use to convert our date with in order to do the
> "LIKE" (I guess we could use the ISO8601 and HTTP-date as format masks and do
> a string compare on that).


No one has proposed that.

Note also that DASL is silent on the underlying comparison logic that a server
uses.  It is perfectly fine for a server to support gt and lt comparisons on
dates where the underlying compare operator is uses time comparisons, not
string comparisons.  On the other hand, one of the nice properties of  ISO8601
is that string comparisons *are* the same as time comparisons.

Note finally that DASL allows servers to define additional operators.  So if
you want to experiment with a date mask, go right ahead.
 
>
> 3)  Character set issues.  I believe there are going to be character set
> issues using the Contains clause, and its not DASL's fault.  When doing
> character sets using properties, there should not be a problem. 


>
> Character Sets Properties - Since the character set of the XML is given,
> servers can convert the request into the character set that the server
> internally uses and do any compares.  This should work without problem
> (assuming the server uses Unicode (or some superset of the possible character
> sets) of some sort for its internal storage.


Note that DASL only defines comparisons between strings when the xml:lang
attribute is identical.

People have pointed out that this is problematic, as it would make a comparison
between a strings in e.g. en_us and en_uk. undefined.  On the other hand,
perhaps it's okay to leave it undefined (servers MAY define it, they just are
not required to)
 
>
> Character Sets for Contains - Unfortunately the server has no control over
> what the character set the files are.  And when files are PUT or uploaded to
> the server using Webdav clients today (well MS), the character-set is not
> sent.  Without being sent the character set of the file, it could be hard to
> search it.  


I suppose you are right.  If the server does not know the underlying character
set, the results may be unpredictable.  Just to be clear, is this an objection
to DASL?

Thanks for your comments.

Might I ask that next time you not use formatted email?  not all mail readers
can handle it.

thanks

Jim

Received on Friday, 15 October 1999 12:08:50 UTC