Hello Lisa,
You're right (read about it in section 14)! Additionally, since <D:principal-URL> element is an ACL xml element (found it out after Thomas email), slide is indeed correctly extending the basic dav specification. Like I said earlier, I will sleep better tonight :) Many thanks, Miguel _________________________ This isn't a RFC2518 conformance problem. The XML specifications in RFC2518 are very careful to show that while certain elements are required, additional elements not defined in RFC2518 MAY appear and should be ignored if they're not understood. That language was carefully added to allow implementations to extend WebDAV without breaking each other. Lisa On Nov 19, 2004, at 4:51 AM, Miguel Figueiredo wrote: > > > Hello folks, > > I got alarmed when producing test units for the webdav LOCK method. > > When locking a resource in slide and executing a propfing in it, I get > returned a typical <D:lockdiscovery> element with a not so typical > <D:principal-URL> element witch it suspect is redundant in presence of > the > <D:owner> element. > > The <D:lockdiscovery> element, or more precisely the contained > <D:activelock> elements can only contain certain elements as specified > in > RFC 2518 section 12.1, witch includes the <D:owner> element but nothing > about a <D:principal-URL>. Well, perhaps the specification is > constraining > us a bit too much, since it does not allow any other kind of elements > to be > used inside the <D:activelock> making it non-extensible (something it's > carefully handled in more modern XML specifications), but at least the > slide-added <D:principal-URL> element SHOULD NOT share the same > namespace of > the dav spec. > > Does someone know if this scenario was agreed upon by the slide team > or if > it was overlooked at implementation time? > > Well, if the <D:principal-URL> element is needed I would suggest > change > it's namespace (I've seen slide xml elements around with the > "http://jakarta.apache.org/slide"; namespace if I remember correctly: it > could be a good namespace for it), if not, remove it completely since > it can > be redundant in presence of the <D:owner> element. > > Best regards, > Miguel > > > PS: I know this is irrelevant to slide functionality, but didn't want > people > start comparing the open-source community with Microsoft's irreverence > in > specifications implementations :) > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
