for every case where a query would be rejected. We seem to agree that
> 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
>
>
