- From: Javier Godoy <rjgodoy@fich.unl.edu.ar>
- Date: Mon, 4 Feb 2008 23:45:40 -0200
- 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 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