more preconditions?, was: draft-reschke-webdav-search-15.txt - draft-reschke-webdav-search-latest.txt

Hi,

FYI: I discussed whether SEARCH should try to specify precondition names 
for every case where a query would be rejected. We seem to agree that 
there's currently not sufficient interest to do so, but that we should 
mention in the "Future Extensions" appendix.

BR, Julian


Javier Godoy wrote:
> Hi Julian,
> 
> Julian Reschke wrote:
> 
>> Actually, the spec currently is sort of silent in most places about error
>> handling.
>>
>> In general I'd expect a server to return 422 for any query that get's
>> through the XML parser, but then can not be executed.
>>
>> Of course it would be nice to have preconditions defined for all this
>> stuff, but in practice we're documenting *existing* servers here, that
>> won't be touched no matter what we write.
> 
> Well... if the preconditions were OPTIONAL, future implementations will be
> aware of them and there would be no backward compatibility issues (per
> WebDAV extensibility rules, if the client receives a response with a
> precondition it does not understand, then it MUST ignore the precondition
> and treat the response as if no precondition had been given, and it 
> would be
> only regarded as a loose hint about the error cause).  This does not make
> current server implementation non-conformant, as they would not be required
> to use the new preconditions.
> 
> I would like to have preconditions for each error that the client could
> recover from, and some preconditions for errors that the client may want to
> log or report to the user (obviously this depends on the intended usage, 
> but
> some common preconditions would enhance interoperability).
> 
> 
>> That being said, we may want to add "enhanced diagnostics" to the Future
>> Extensions appendix.
> 
> +1, IMHO it will require a careful analysis, in order to not introduce
> preconditions with insufficient information, or preconditions which would
> not be useful to the client but only complicate the protocol. I think it
> will require some time to get appropriate feedback about this, then it will
> be best addressed later instead of delaying the core SEARCH specification.
> 
> (You may foward this mail to the list if you think it helps for documenting
> this issue.)
> 
> 
>>> (off-topic) Did you looked at
>>> http://www.ietf.org/internet-drafts/draft-godoy-webdav-xmlsearch-02.txt
>>> ?
>>> maybe it is too complex to be useful and some features should be
>>> simplified or removed...  but I'm not sure, sometimes I think it 
>>> might be
>>> an interesting step (at least for discussion), and sometimes I think it
>>> is babble and I want it to expire... (currently I'm biased towards the
>>> latter)
>>
>> I did some time ago, but back then, I was kind of frustrated because
>> SEARCH itself was stuck in the IESG. But now I may want to get back to 
>> it.
>>
>> When you wrote it, did you have a specific application in mind, or was
>> this just an experimental thing?
> 
> I had an specific application: repositories where resources are described
> according to the IEEE standard for Learning Object Metadata (LOM) [1], 
> which
> is encoded as an XML document [2]. An application-specific search grammar
> for this schema would have worked, but it sounds as reinventing the wheel
> several times. On the other hand, I think that someone else could benefit
> from some discussion (and a proposal, and third-party mistakes ;-) about 
> how
> to perform massive XPath queries through the SEARCH method,  then I'm 
> trying
> to write something which can be used for other XML properties (and 
> something
> I will not have to review if the LOM schema is updated, which will occur in
> some years time).
> 
> Of course, I would have used DAV:basicsearch if I had had non-repeatable
> elements, but the LOM XML schema allows repeatable elements virtually
> everywhere [3].
> 
> [1] http://ltsc.ieee.org/wg12/files/LOM_1484_12_1_v1_Final_Draft.pdf
> [2] http://ltsc.ieee.org/wg12/files/IEEE_1484_12_03_d8_submitted.pdf
> [3] http://en.wikipedia.org/wiki/Image:LOM_base_schema.png
> 
> 
>> BTW: Jackrabbit (the Apache RI of the Java Content Repository stuff)
>> implements it's own XPath based grammar, in case you didn't know.
> 
> I didn't. I should investigate it, thanks for the hint.
> 
> 
> Best Regards
> 
> Javier
> 
>

Received on Saturday, 28 June 2008 10:39:29 UTC