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

Julian Reschke wrote:
> 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).

+1

I had proposed describing character data as an operand because I though you
were allowing it in any case, with no restrictions.

I consider it would be OK if this "operand" were NOT RECOMMENDED,
allowed only for DAV:contains, because of legacy reasons.


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

No, I'm not aware of any client implementing this feature... I think it
could be a good enhancement because the client application is not required
to undestand the semantics of each operator (it is up to the user). Thus, if
the client already deals with some signature (e.g. a single property
operand) it could deal with other operators of the same signature. Of
course, not every client is intended for human consumption, and there are
advantages and disadvantages with this approach...

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

Good choice for natural language, too long for an element name... after all,
pcdata stands for (parsed) character data.

Best Regards

Javier

Received on Wednesday, 6 February 2008 18:20:18 UTC