W3C home > Mailing lists > Public > www-webdav-dasl@w3.org > January to March 2008

Re: QSD description for DAV:contains in DAV:basicsearchschema

From: Javier Godoy <rjgodoy@fich.unl.edu.ar>
Date: Mon, 4 Feb 2008 23:45:40 -0200
Message-ID: <005201c86798$d2f04230$017ba8c0@Javier>
To: "Julian Reschke" <julian.reschke@gmx.de>
Cc: <www-webdav-dasl@w3.org>, "Julian Reschke" <julian.reschke@greenbytes.de>

Julian Reschke wrote:

> Javier Godoy wrote:
>> 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>

This is simple (and less intrusive than adding "operand-pcdata"), but it is
also ambiguous because an operator accepting character data would be
described as if it had a void signature.

If this approach is adopted, it must be worded carefully. Would it be an
exceptional rule for handling DAV:contains? If it is not, it might imply
that *any* operator described in QSD allows character data (or mixed
content!), when actually it is a particular case.

Well... this is not a problem with DAV:contains, because it is already
defined as allowing character data, and overloading it with a void signature
makes no sense. However, general-purpose clients may use the information
provided in the QSD response (when the server supports this feature) for
allowing users to specify additional operators and/or validate the requests
prior to submission. Therefore, when describing other implementation-defined
operators, it might be useful to provide different representations for each
case. For instance, suppose there is an extension operator similar to

<!ELEMENT is-principal EMPTY >

If it is described as

<opdesc xmlns=":DAV" xmlns:F="http://example.com/foo">

it could be (mis)understood as

<!ELEMENT is-principal (#PCDATA) >

Which clearly is not the intent.

>> 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>

I see... since character data is "non-positional", the proposed
DAV:operand-pcdata element cannot be added to the list of operand types in
5.19.8 (which are defined as sorted according to the corresponding

> -- do you want propose text for that?

5.19.1,  Add:
    <!ELEMENT operand-pcdata   EMPTY>

5.19.8, within first paragraph,

The listing for an operator consists of the operator (as an empty element),
followed by one element for each operand /*, and an optional ocurrence of
The operand MUST be either DAV:operand-property, DAV:operand-literal or
DAV:operand-typed-literal, which indicate that the operand in the
corresponding position is a property, a literal value or a typed literal
value, respectively. /*If  the operator allows character data, then
DAV:operand-pcdata MUST be included once.*/


Note: Instead of  "operand-pcdata", it might be named differently (e.g.
"pcdata-allowed"), in order to emphasize it is not a "positional" operand as
the other operand-* are.

Best Regards,

Received on Tuesday, 5 February 2008 01:46:03 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:22:44 UTC