you can remove this element by changing an init-param in the web.xml file. looks like there was a request to add this parameter in the spec :
<init-param>
<param-name>lockdiscoveryIncludesPrincipalURL</param-name>
<param-value>true</param-value>
<description>
As proposed on February 08, 2003 by Lisa Dusseault in
[EMAIL PROTECTED], the DAV:lockdiscovery property should
include an element DAV:principal-URL with the semantics of the
WebDAV/ACL specification. This feature can be switched-off in case
of interoperability problems.
</description>
</init-param>
thomas
Le 19 nov. 04, � 13:51, Miguel Figueiredo a �crit :
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]
