W3C home > Mailing lists > Public > www-webdav-dasl@w3.org > October to December 2002

RE: gte vs. numerical property values

From: Wallmer, Martin <Martin.Wallmer@softwareag.com>
Date: Tue, 22 Oct 2002 16:35:02 +0200
Message-ID: <DFF2AC9E3583D511A21F0008C7E6210602D90587@daemsg02.software-ag.de>
To: "'Julian Reschke'" <julian.reschke@gmx.de>, www-webdav-dasl@w3.org


good idea to deal with datatypes :-)

some questions
how the server may happen to have information about the type of a dead

what if the server knows about the datatype, and the type in the query does
not match?


-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Dienstag, 22. Oktober 2002 13:47
To: www-webdav-dasl@w3.org
Subject: DAV:gte vs. numerical property values


let's consider a dead property "foo", and some resources a, b and c on which
this dead property is defined and has the values "1", "3" and "10".

Consider a DAV:basicsearch with the where clause:

<gte xmlns="DAV:">
  <prop><foo xmlns=""/></prop>

Which resource will match?

As DAV:basicsearch currently isn't type-aware, the server will have to do a
string comparison, and only the b (with value "3") will match.

Is this really sufficient? It basically means that dead property comparisons
are restricted to strings.


a) If the server happens to have type information for a dead property, it
should try to do a comparison according to the known property type, if the
literal can be parsed into this type. This basically replicates the
behaviour that a client would expect when querying on live properties such
as DAV:getcontentlength, so it could be taken as a simple clarification.

Extended proposal:

b) A client can enforce comparison using a specific data type by specifying
the type in the query, for instance using:

<gte xmlns="DAV:">
  <prop><foo xmlns=""/></prop>
  <literal xsi:type="xs:long">3</literal>



<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Tuesday, 22 October 2002 10:35:08 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:22:43 UTC