RE: must property names be empty and attributeless?

This suggestion comes too late for draft-ietf-webdav-protocol-08 but
there is a way that the DTD could be modified to make it impossible to
have attributes associated with the properties being requested (Perhaps
this document is simply for use in any future WebDAV work). The
technique uses one of those features of XML that is explained so well in
the XML 1.0 spec ;-)

Instead of how things are currently expressed in syntax, e.g.:
 <D:propfind>
   <D:prop>
     <D:getcontentlength/>
     <X:shoesize/>
   </D:prop>
</D:propfind>

The same intent could have been expressed as:
<D:propfind props="D:getcontentlength X:shoesize" />

The DTD would be modified as:
<!ELEMENT propfind EMPTY>
<!ELEMENT propfind props NMTOKENS #REQUIRED>

The point is that the type of the props attribute is NMTOKENS. The
immediate benefit is that a name token cannot have attributes. More
subtlely, the possible NNTOKEN's are very well defined in XML 1.0:

[8]  Nmtokens ::=  Nmtoken (S Nmtoken)* 
[7]  Nmtoken ::=  (NameChar)+ 
[4]  NameChar ::=  Letter | Digit | '.' | '-' | '_' | ':' |
CombiningChar | Extender 

Which essentially allows for almost any no-whitespace UNICODE string as
the name of a property including a possible namespace prefix. So the
props attribute would be a list of property names expressed as
NMTOKEN's, each serperated from its neighbors by whitespace.

Such a DTD design would, if desired, prevent creative interpretation of
the WebDAV spec such as Jim is pointing out and make the issue of
"content negotiation" on properties mute.


> -----Original Message-----
> From: Yaron Goland [mailto:yarong@microsoft.com]
> Sent: Tuesday, July 14, 1998 4:31 PM
> To: 'Jim Davis'; w3c-dist-auth@w3.org
> Subject: RE: must property names be empty and attributeless?
> 
> 
> An explicit design decision for properties is that they are 
> NOT resources.
> In HTTP resources handle content negotiation. If you need content
> negotiation then you need a resource.
> 
> However it is possible for the server to return you a URL 
> which can resolve
> to the same value as an associated property. So if I ask for 
> the author
> property I will get a static result, negotiation is strictly 
> not allowed.
> However it would be perfectly fine to also get back an 
> extension to the
> multistatus format that returns a URL associated with that 
> property. That
> URL could then be resolved using content location.
> 
> 			Yaron
> 
> > -----Original Message-----
> > From: Jim Davis [mailto:jdavis@parc.xerox.com]
> > Sent: Saturday, June 20, 1998 6:32 PM
> > To: w3c-dist-auth@w3.org
> > Subject: must property names be empty and attributeless?
> > 
> > 
> > In all extant examples of PROPFIND, the names of the 
> properties to be
> > fetched are always passed as empty tags, e.g.
> > 
> > <D:propfind>
> >  <D:prop>
> >    <D:getcontentlength/>
> >    <X:shoesize/>
> >  </D:prop>
> > </D:propfind>
> > 
> > Is there anything in the DTD that mandates that the property 
> > names be empty
> > and have no attributes?  The DTD for prop is ANY, which seems 
> > to allow it,
> > but perhaps there are unstated assumptions that the tags be empty.
> > 
> > To motivate this, suppose I have a property store that can 
> > express the same
> > underlying value in one of several units, e.g. metric or 
> > english.  I'd like
> > the PROPFIND client to be able to express a choice of units.  
> > There are at
> > least three ways this could be done.
> > 
> > 1) Express the units with a tag within the property (thus it 
> > ceases to be
> > empty), e.g.
> > 
> > <D:propfind>
> >  <D:prop>
> >    <X:shoesize>
> >      <X:units><X:metric/></X:units>
> >    </X:shoesize>
> >  </D:prop>
> > </D:propfind>
> > 
> > 2) Express the units as an attribute of the property
> > 
> > <D:propfind>
> >  <D:prop>
> >    <X:shoesize units="metric"/>
> >  </D:prop>
> > </D:propfind>
> > 
> > Are either or both of these approaches allowed by WebDAV?
> > 
> > As for the third way, it is awful:  Express the units by 
> > concatenating them
> > into the name of the property itself.  I mention it only to 
> > prevent some
> > kindly soul from suggesting it to me as a workaround.
> > 
>

Received on Wednesday, 15 July 1998 14:19:07 UTC