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

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
DAV:is-collection:

<!ELEMENT is-principal EMPTY >

If it is described as

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

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
position).

> -- 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
DAV:operand-pcdata*/.
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,

Javier

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