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

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

We could consider just to state that DAV:contains is an exception, and 
discourage the use of this format for other operators. (We should have 
made DAV:contains use DAV:literal, but that's too late now).

> 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

Out of curiosity: have you seen a client using this information?

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

Yes.

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

I'd probably try to avoid the term "pcdata" here, because it's a very 
XML-DTDish term, as opposed to "characters" as used in the XML Infoset.

BR, Julian

Received on Tuesday, 5 February 2008 12:15:03 UTC