RE: (another) SEARCH draft update

> From: Kevin Wiggen [mailto:kwiggen@xythos.com]
> Sent: Tuesday, October 07, 2003 11:46 PM
> To: Julian Reschke; www-webdav-dasl@w3.org
> Subject: RE: (another) SEARCH draft update
> 
> 
>  
> 
> I have been thinking about this QSD on my recent travels and the 
> option to query for what operators the system can support.  I 
> still believe that the supported operators can definitely change 
> on a property by property case and therefore getting a list of 
> all supported operators is useless (what if I have a byte[] 
> property, I can do all sorts of fancy operators that won’t work on dates).

Yes. I already stated that it seems that we have a different understanding about what "supported" means. My understanding is that it means that the server knows the operator, not necessarily that it will be possible to apply it to every conceivable property.

Please check: <http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-latest.html#rfc.section.5.19.8>

> So I was thinking about taking a step back and looking at what 
> DASL is based on, SQL.
> 
>  
> 
> In SQL you can’t do anything like QSD.  You can’t ask for 
> operators, you can’t ask for what queries it supports.  It simply 
> is a vocabulary you can use.  (I would argue that it is used 
> quite well by a number of people to, and it’s quite successful.  
> Perfect, no, but useful).

Yes. But the difference here is that in an SQL table, the type for a single field will be the same for all records in a table, but this isn't necessarily the case for DAV properties in a HTTP namespace. Thus the spec somehow needs to address that. Currently it says under DAV:literal (<http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-latest.html#rfc.section.5.10>):

--
In comparisons, the contents of DAV:literal SHOULD be treated as string, with the following exceptions: 

- when operand for a comparison with a DAV:getcontentlength property, it SHOULD be treated as an integer value (the behaviour for non-integer values is undefined), 
- when operand for a comparison with a DAV:creationdate or DAV:getlastmodified property, it SHOULD be treated as a date value in the ISO-8601 subset defined for the DAV:creationdate property ([RFC2518], section 13.1). 
- when operand for a comparison with a property for which the type is known, it MAY be treated according to this type. 
--

That seems to be the bare minimum we need to say to make DAV:basicsearch well-defined for at least the standard RFC2518 properties.

What's left is the ability for the client to suggest the intended typing if the server does *not* know the type of the properties being queried, or alternatively, if the type of the property varies across the resources in scope.

Note that this is similar to the typing issues in XPath/XSLT/XQuery. Guess what? They allow you to cast the elements being queries.

> The way SQL handles the problem is through better error messages. 
>  This might be the way to go.  Maybe instead of spending energy 
> on QSD, we should work on error reporting.  If a client could get 

I agree that we need to work on error reporting anyway (if you look at the latest draft, I already started to do that). That doesn't necessarily mean that QSD becomes useless, though.

> an error stating a server doesn’t support LIKE on a Date, it 
> would know what to do (or at least could give a valid answer to 
> the user).  If a server DOES use QSD and state its supported 
> operators, error messages would still need to be built as the 
> server probably will not support all operators for all 
> properties.  Taking this down to the simple case (for 

Correct.

> dav:simplequery), why don’t we simply state here are the known 
> possible operators (gt,lt,like,eq,etc) and then let error 
> messages tell the client what went wrong.  I agree that it might 

The <operators> element is used to report only *optional* operators, anyway. So if you don't implement any of the optional operators, just don't do anything in QSD. But if you *do* implement optional operators, you will be aware of that (right?), in which case it's trivial to return that list.

> be nice to know this up front, but the information deemed by the 
> QSD in proposal is almost no better than the spec stating here 
> are the operators.  The client still needs to handle error cases, 
> or we need to do operators on a property by property basis (which 
> is overkill right now).  So I would like to make the argument for 
> better errors in DASL, than QSD operators.  I think in the long 
> run it will help clients build interoperability as they will be 
> able to do the right things in all cases.  I also argue that SQL 
> has gotten away pretty well without letting operators be queried.
>
> SQL also doesn’t have a way of asking what queries you can make 
> (its too complex).  You can however ask a table for its values, 
> which I argue is very much like a propfind.  I can ask a node in 
> webdav for its properties and build a query page from that.  
> Asking a node its properties through propfind is the same as a 
> QSD in the worst case.  As I have mentioned before, every node 
> could have completely different properties and therefore asking 
> for a QSD to query them either has to be defined (is it the AND 
> of all the known properties, the OR) so that clients build 
> consistent UI’s, or left out.

Again: it's not the goal of QSD to do that.

> For now I again say we continue to mirror after SQL and build 
> better errors than list operators.  And I continue to state that

Just because we do one thing doesn't necessarily mean the other thing is useless. Please keep in mind that querying DAV properties is fundamentally different than using SQL to query tables. Where they are similar, this is good and we should do re-use (such as DAV:like). Where they aren't, we need to address this.
 
> querying properties in a QSD is not needed for basicsearch and 
> could be done with propfind if the client wanted to.  By simply 
> stating a query language and error messages we will not be tied 
> to any decisions that limit the way properties can be used in the 
> future (like allowing for a byte[] property in webdav). 

Please be more specific. How does the current draft affect property handling in WebDAV?

> BTW - SQL doesn't have datatypes in its language either, you get 
> back the datatype of the value, that's all (well without doing 
> casting which is too complex for dasl right now). If you use a 
> column in a where clause, its up to you to know the datatype and 
> how that will sort.   The argument that a client needs datatyping 
> to build a search screen falls apart when you think that the SQL 
> query language has gotten away with it for a long while.  For the 
> known DAV: properties its pretty obvious what the datatype is, 
> therefore the sorting, etc should be consistent.

That's true, but it still needs to be stated in the spec (that's in section 5.19.8).

Julian


--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Friday, 10 October 2003 07:59:43 UTC