- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Mon, 04 Feb 2008 12:32:07 +0100
- To: Javier Godoy <rjgodoy@fich.unl.edu.ar>
- CC: www-webdav-dasl@w3.org, Julian Reschke <julian.reschke@greenbytes.de>
Javier Godoy wrote: > > Julian, > > Section 5.19.8 of draft-reschke-webdav-search-14 requires that "All > optional operators that are supported MUST be listed in the > DAV:operators element. The listing for an operator consists of the > operator (as an empty element), followed by one element for each > operand. The operand MUST be either DAV:operand-property, > DAV:operand-literal or DAV:operand-typed-literal (...)" > > But the optional operator DAV:contains cannot be described in these > terms, because > its content model is defined to be (#PCDATA) and there is no operand > descriptor for #PCDATA content. That's correct. I just checked why I didn't catch this when I implemented QSD in my server, and of course it's because it doesn't supports DAV:contains. > Is there any conforming way of describing DAV:contains? One could argue that the character data isn't a "positional" parameter, and thus doesn't need to be listed (kind of weak, I agree). That would make it: <opdesc xmlns=":DAV"><contains/></opdesc> > IMHO, a possible solution would be defining a "DAV:operand-pcdata" > element, so the following construct would be valid: > > <opdesc xmlns='DAV:'> > <contains/> > <operand-pcdata> > </opdesc> I just tried that, but it would require some cleanup in <http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-latest.html#rfc.section.5.19.8> -- do you want propose text for that? Otherwise I'd propose to stick with the simpler proposal; describe it in one sentence, and add it to the example in <http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-latest.html#rfc.section.5.19.9>. BR, Julian
Received on Monday, 4 February 2008 11:32:26 UTC