more preconditions?, was: draft-reschke-webdav-search-15.txt - draft-reschke-webdav-search-latest.txt
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.
Javier Godoy wrote:
> Hi Julian,
> Julian Reschke wrote:
>> Actually, the spec currently is sort of silent in most places about error
>> 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,
> 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
>> 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
>> 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) ,
> is encoded as an XML document . 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
> to perform massive XPath queries through the SEARCH method, then I'm
> to write something which can be used for other XML properties (and
> 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 .
>  http://ltsc.ieee.org/wg12/files/LOM_1484_12_1_v1_Final_Draft.pdf >  http://ltsc.ieee.org/wg12/files/IEEE_1484_12_03_d8_submitted.pdf >  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