You are viewing a plain text version of this content. The canonical link for it is here.
Posted to slide-dev@jakarta.apache.org by Miguel Figueiredo <mf...@maisis.pt> on 2004/11/19 13:51:10 UTC
RFC2518 conformance conflict?
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: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
RE: RFC2518 conformance conflict?
Posted by Miguel Figueiredo <mf...@maisis.pt>.
Thank you Thomas, I'll sleep better tonight
:)
Miguel
-----Original Message-----
From: Thomas Draier [mailto:thomas.draier@codeva.net]
Sent: sexta-feira, 19 de Novembro de 2004 14:13
To: Slide Developers Mailing List
Subject: Re: RFC2518 conformance conflict?
hi,
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
w3c-dist-auth-request@w3.org, 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: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: RFC2518 conformance conflict?
Posted by Thomas Draier <th...@codeva.net>.
hi,
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
w3c-dist-auth-request@w3.org, 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: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
RE: RFC2518 conformance conflict?
Posted by Miguel Figueiredo <mf...@maisis.pt>.
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: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: RFC2518 conformance conflict?
Posted by Lisa Dusseault <li...@osafoundation.org>.
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: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org