- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Sat, 18 Oct 2003 01:55:52 +0200
- To: "WebDAV Discussion List" <w3c-dist-auth@w3.org>
> From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Dennis E. Hamilton > Sent: Friday, October 17, 2003 11:48 PM > To: WebDAV Discussion List > Subject: duplicate properties (was rfc2518bis DAV DTD ...) > > > > This note seems to have gone into a hole somewhere [it is not on > the archive] so I am resending it for completeness. Now if I > could figure out why I receive two of everything, that would be a > good thing. -- dh People pressing "reply to all"... > Julian, > > Thanks for the comment on the example. I did that intentionally, > because there is an existing example (8.2.1 in bis-04) that > repeats a property, in effect, but inside of a wrapper, and I > wanted to see what attention this one would attract. Could you be more specific? I don't see a duplicate property name there. > (There is also an error in my <error> element example. I left > out the "/" before ">" of the empty element. It should be > <forbid-external-entities />.) > > There is an issue that will arise with the unique property > requirement. Other uses of ad hoc properties in XML applications > are not limited to single occurrences of property elements for > the same property. (Property-asserting elements are seen as > predicates or establishment of a relationship, and many-to-many > is commonplace.) The example I gave would be appropriate if I > was mapping something from RDF to DAV, for example. This may > become a problem as the Semantic Web and DAV collide. Well, that's how WebDAV works. If you need multi-valued properties (such as when mapping DC to WebDAV properties), you need to come up with a WebDAV-compatible way to do it. See for instance: <http://ftp.ics.uci.edu/pub/ietf/webdav/dc/draft-ietf-webdav-dublin-core-01. txt> > I assume that the appropriate DAV treatment would be to wrap a > bundle of RDF properties inside a single DAV property and pray. > This is a new topic and probably becomes something to identify as No, it's absolutely not new. See above. In fact, our server already supports extraction of DC-encoded metadata from HTML content and mapping to WebDAV properties. If there are more people interested on a common format, please email me. > an open/future item without resolution in 2518bis. It is part of > the overall question of relationship to other applicable > standards, such as XML digital signatures and encryption, XML > Schema, SOAP/XML-HTTP, UDDI, RDF-XML, and other Web Service and > Semantic Web specifications that may have some bearing on DAV > applications. > > -- Dennis > > Side Note: From my background with DMS and especially DMA, I > would find it natural to prohibit duplicate assertions about the > same property. > > Having worked with other XML-based specifications for a while, I > see that is not the course being taken. What I learn from that > is that I have been subjecting the protocol to the constraints of > an envisioned storage model: I am using ideas about > storage-system implementation to place tacit constraints on the > request/response protocol for which there is no abstract > justification. That's a lesson for me. > > It's apparently a lesson in W3C work too. Later specifications > are being abstracted above the XML InfoSet and even above XML > altogether. The difference in specification models between SOAP > 1.1 and SOAP 1.2 is informative in that regard. The same arises > in the Working Documents for revisions of RDF and in other > Semantic Web specifications (e.g., OWL). I don't know what the > lesson might be for DAV. -- dh At the end of the day, that's just an aspect of marshalling in WebDAV. As properties can have arbitrary XML content, there's no problem mapping these multi-valued properties to WebDAV. The only things that's missing is a common format. So far, the interest in agreeing on one seems to be little. Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Friday, 17 October 2003 19:56:17 UTC