RE: Format of DAV:get* properties

This hasn't been a problem in the WFS implementation.  The unusual
formatting is rare, and so users can generally search on "contains 
'text/plain'" and get all the results they need.  Sometimes it's 
not worth dealing with edge cases in a spec, beyond noting that 
they exist and noting that servers can easily normalize the value
to reduce the existence of edge cases.

However, I'm not sure how much of an edge case it is.  If it's been
a problem in practice, the 'media-type-match' syntax seems to be an
elegant and effective way to deal with it.

Lisa

> -----Original Message-----
> From: www-webdav-dasl-request@w3.org 
> [mailto:www-webdav-dasl-request@w3.org] On Behalf Of Julian Reschke
> Sent: Tuesday, November 25, 2003 3:18 AM
> To: 'www-webdav-dasl@w3.org'; w3c-dist-auth@w3c.org
> Subject: Format of DAV:get* properties
> 
> 
> 
> Hi,
> 
> I was just trying to come up with a DAV:basicsearch query that would 
> match on the DAV:getcontenttype property (instead of making 
> assumptions 
> about file names).
> 
> However, a combination of
> 
> - complex media type syntax 
> (<http://greenbytes.de/tech/webdav/rfc2616.html#media.types>),
> - HTTP white space handling in headers and
> - deficiencies in the DAV:like operator
> 
> makes this *really* hard. To illustrate the problem, all of the 
> following are legal values for the HTTP content-type header for a 
> "text/plain" resource:
> 
> 1) "text/plain"
> 
> 2) "text/plain; charset=UTF-8"
> 
> 3) "text/plain ; charset=UTF-8"
> 
> 4) "text/plain;\tcharset=UTF-8"
> 
> 5) "text/plain\r\n\t;charset=UTF8"
> 
> (where \r, \n and \t are CR, LF and HT).
> 
> If we add linear white space at the start of the attribute 
> value, things 
> get even more complicated.
> 
> One way to approach this issue is to find out whether existing DAV 
> servers indeed use all these variants, or whether in practice only 
> single SPs appear as whitespace (which would make sense in 
> DAV:getcontenttype). In that case, we'd only need to consider 
> variants 
> 1...3.
> 
> Alternatively, the SEARCH spec could state that matching on DAV:get* 
> headers occurs after whitespace normalization.
> 
> In both cases, a match for "text/plain" could be expressed as:
> 
> (DAV:getcontenttype LIKE "text/plain") OR (DAV:getcontenttype LIKE 
> "text/plain %") OR (DAV:getcontenttype LIKE "text/plain;%")
> 
> This is still ugly, but if we add that as example to the 
> spec, servers 
> may be able to optimize this case internally.
> 
> An alternative would be to add a specific operator that 
> specializes on 
> matching media types minus parameters, such as
> 
> <media-type-match>
>    <type>text</text>
>    <subtype>plain<</subtype>
> </media-type-match>
> 
> where both child elements would be optional and probably use 
> LIKE syntax 
> (in caseless mode).
> 
> Feedback appreciated,
> 
> Julian
> 
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> 
> 
>

Received on Tuesday, 25 November 2003 12:41:12 UTC