RE: Questions/Comments on DASL

>
> 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"?

<KW> I think DASL is still usable.  Hopefully most result sets will be small
and thus prev/next are not needed.  If DASL did not want to put it into V1,
I would not complain.  It was just a natural extension, I was looking
through the spec afterward trying to find how to do prev/next.
</KW>

>
> 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),
>
>  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.

<KW>  OK let me rephrase my question a little using your response.  There
are currently 2 dates (at least) defined as server live properties in
Webdav.  Creationdate uses ISO8601.  So I assume from your response, that I
can assume that ALL requests to my server in DASL will use ISO8601 when
referring to creationdate.  Internally I use a date column, so I will be
using date compares for gt, lt, etc.  But when it comes to LIKE, I need to
give a date-format mask to my compare function, otherwise my code will pick
a date-format mask (which is not ISO8601), and all the string compares will
fail.

So I am not proposing anything new.  I just wanted to make sure that ALL
creationdate requests (even LIKE) will use ISO8601 to format the date.  I
can then do the correct formatting to check against my internal date value.

I also assume that ALL lastmodifieddate property compares will use HTTP-date
as the format.  Again without the format, my comparisons are tough to do, as
internally I have milliseconds from the epoch stored.

I believe language that explains that the date values MUST be in the
appropriate format should be added to the spec, otherwise integration will
be tough.

</KW>

>
> 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?

<KW> Not an objection to DASL, but more of a red flag.  If we really want
this to work, we need to push on the WEBDAV clients (and browsers) to send
servers the correct information (including charset)

</KW>

Kevin

Received on Monday, 18 October 1999 15:16:34 UTC