Re: question about draft-reschke-webdav-search-13

Javier,

not that the document is past several last calls and in state
"publication requested" for several months now.

So, I'm not too excited to do any major changes enhancing the DTD. In
future specs, I'd choose Relax NG over it anyway.

Best regards, Julian

Javier Godoy wrote:
> 
> 1. Right... I forgot the empty operator element. At a first glance, it 
> seems we are forced to use ANY as the content model because there are no 
> wildcard elements for the content model declaration.
> 
> <!ELEMENT opdesc               ANY>
> 
> Well, since WebDAV messages are not *strictly* valid against the DTD 
> (because of the additional features), and RFC 4918 states that  "A 
> recipient of a WebDAV message with an XML body MUST NOT validate the XML 
> document according to any hard-coded or dynamically-declared DTD.", it 
> follows that the DTD is only an XML-oriented grammar ruleset, further 
> constrained by natural-language rules (e.g. handling of unknown 
> elements, irrelevant ordering, value constraints, context-sensitive 
> content etc)
> 
> If we defined a parameter entity which represents all the operators 
> (either defined or not defined by WebDAV SEARCH), we would be able to 
> express DAV:opdesc content model in a more detailed way.
> 
> <!ENTITY %all_supported_ops       "%all_ops;" --%all_ops; or a model 
> group of alternative (OR-ed) operators not defined in this 
> specification-- >
> 
> <!ELEMENT opdesc
>  ( (%all_supported_ops;) 
> (operand-literal|operand-typed-literal|operand-property)* ) >
> 
> Hera (%all_supported_ops;) is a placeholder for a single operator 
> element. Thus, a server implementation would replace %extension_ops by 
> the actual additional operators it is supporting. A client would expect 
> a single element (possibly unknown) in that place, followed by the 
> operands kind (both behaviours conforms the current sintax, it is only a 
> different way of expressing that in the specification with less ambiguity.)
> 
> 2. Note the occurrence indicator should be REP * instead for PLUS +  
> since we should be able of defining new non-standard operators without 
> operands (which work in same way than DAV:is-collection)
> 
> now, the following opdesc is valid
> <D:opdesc xmlns="DAV:">
>  <is-principal xmlns=urn:fdc:fich.unl.edu.ar:2007:DAV:"/>
> </D:opdesc>
> 
> 3. A complete representation of operators by means of DAV:opdesc 
> requires the possibility of declaring additional operators whose 
> operands are nested operations (the same way DAV:and, DAV:OR and DAV:NOT 
> works). Alternatively, if this kind of exception is disallowed by WebDAV 
> SEARCH specification, that should be clearly stated somewhere.
> 
> <!ELEMENT opdesc
>  ( (%all_supported_ops;) 
> (operand-literal|operand-typed-literal|operand-property|operand-nested-op)*  
> ) >
> 
> <!ELEMENT operand-nested-op EMPTY>
> 
> <D:opdesc xmlns="DAV:">
>  <xor xmlns=urn:fdc:fich.unl.edu.ar:2007:DAV:"/>
>  <DAV:operand:nested-op>
>  <DAV:operand:nested-op>
> </D:opdesc>
> 
> An implementation aware of the abovementioned non-standard operators 
> (xor and is-principal), would understand %all_supported_ops; as:
> 
> <!ENTITY %all_supported_ops       "%all_ops; | 
> urn:fdc:fich:unl.edu.ar:2007:DAV:xor | 
> urn:fdc:fich:unl.edu.ar:2007:DAV:is-principal " >
> 
> Regards
> 
> Javier

Received on Tuesday, 23 October 2007 16:44:26 UTC