Cyrus Daboo | 7 Jun 2010 15:40
Favicon

ACL: DAV:privilege element - multiple child elements?

Hi,
RFC3744 defines DAV:privilege as:

<!ELEMENT privilege ANY>

"ANY" technically implies one or more child elements. However, all examples 
in 3744 have just a single child. It has been my assumption that only one 
child is allowed. However, I recently came across a server that is 
returning multiple child elements. So what is, or is not, allowed here?

--

-- 
Cyrus Daboo

Cyrus Daboo | 7 Jun 2010 15:57
Favicon

WebDAv collection sync: last issue

Hi folks,
The latest WebDAV collection sync draft is here: 
<https://datatracker.ietf.org/doc/draft-daboo-webdav-sync/>. We believe we 
are close to done with this and would like to submit to the IESG soon. 
However, there is one open issue that we need feedback from implementors on.

The question is whether collection resources that are immediate children of 
the collection being targeted for the REPORT should be reported as 
"modified" if any of their child resources (depth infinity) are modified.

Key points:

1) We have deliberately scoped the REPORT defined in this draft to be 
Depth:1 only - i.e. it will only report changes to immediate children. 
Depth:infinity change reporting was ruled out at this time (though 
eventually we would expect to see it defined if there is interest).

2) The first real implementations of this REPORT are being done for CalDAV 
and CardDAV servers where typically calendar/addressbook collections only 
have immediate child resources and not collections - so the draft as 
currently written is fine. (BTW there are already several client and server 
implementations of this draft that have been tested at various interops). 
However, my concern is that more "general" WebDAV servers may wish to do 
reporting of changes to immediate child collections to allow clients to 
progressively sync an entire hierarchy.

3) Reporting changes to immediate child collections requires any change at 
depth:infinity within those collections to "bubble up" - i.e. a change with 
a collection changes its DAV:sync-token and the properties of all its 
parent collections. This potentially places a big performance burden on the 
(Continue reading)

Julian Reschke | 7 Jun 2010 16:10
Picon
Picon

Re: ACL: DAV:privilege element - multiple child elements?

On 07.06.2010 15:40, Cyrus Daboo wrote:
> Hi,
> RFC3744 defines DAV:privilege as:
>
> <!ELEMENT privilege ANY>
>
> "ANY" technically implies one or more child elements. However, all
> examples in 3744 have just a single child. It has been my assumption
> that only one child is allowed. However, I recently came across a server
> that is returning multiple child elements. So what is, or is not,
> allowed here?

The spec really doesn't say.

On the other hand, the intent is pretty clear, because in the cases 
where multiple privileges can be listed, it's the *parent* element that 
would occur multiple times.

Best regards, Julian

Cyrus Daboo | 7 Jun 2010 16:18
Favicon

Re: ACL: DAV:privilege element - multiple child elements?

Hi Julian,

--On June 7, 2010 4:10:00 PM +0200 Julian Reschke <julian.reschke <at> gmx.de> 
wrote:

>> "ANY" technically implies one or more child elements. However, all
>> examples in 3744 have just a single child. It has been my assumption
>> that only one child is allowed. However, I recently came across a server
>> that is returning multiple child elements. So what is, or is not,
>> allowed here?
>
> The spec really doesn't say.
>
> On the other hand, the intent is pretty clear, because in the cases where
> multiple privileges can be listed, it's the *parent* element that would
> occur multiple times.

Can you add a comment to your ACL spec update work to clarify this? I think 
some text for the two (yes there are two) DAV:privilege definitions making 
it clear that there is only one child would be good. Either that or the 
definition of DAV:privilege is given its own section with appropriate 
description of its content.

--

-- 
Cyrus Daboo

Julian Reschke | 8 Jun 2010 09:18
Picon
Picon

Re: ACL: DAV:privilege element - multiple child elements?

On 07.06.2010 16:18, Cyrus Daboo wrote:
>>> "ANY" technically implies one or more child elements. However, all
>>> examples in 3744 have just a single child. It has been my assumption
>>> that only one child is allowed. However, I recently came across a server
>>> that is returning multiple child elements. So what is, or is not,
>>> allowed here?
>>
>> The spec really doesn't say.
>>
>> On the other hand, the intent is pretty clear, because in the cases where
>> multiple privileges can be listed, it's the *parent* element that would
>> occur multiple times.
>
> Can you add a comment to your ACL spec update work to clarify this? I
> think some text for the two (yes there are two) DAV:privilege
> definitions making it clear that there is only one child would be good.
> Either that or the definition of DAV:privilege is given its own section
> with appropriate description of its content.

For now, I just added the issue.

To actually make a change we need some sort of consensus over here.

Would people be ok to consider this a clarification, and just to add a 
comment to the DTD, such as

   <!ELEMENT privilege ANY>
   <!-- contains exactly one child element, identifying the privilege -->

?
(Continue reading)

Weber, Heiko | 7 Jun 2010 17:18

RE: DAV:privilege element - multiple child elements?

How about creating XML Schemas for all WebDAV XML response and request
documents, so that it is really clear what is meant? We have created
such XML schemas for at least some of the documents when we implemented
the WebDAV support in the Tamino XML Server and can share these, if
there is some place where they could be put...

best regards,
 Heiko Weber

-----Original Message-----
From: w3c-dist-auth-request <at> w3.org [mailto:w3c-dist-auth-request <at> w3.org]
On Behalf Of Cyrus Daboo
Sent: Monday, June 07, 2010 3:40 PM
To: WebDAV
Subject: ACL: DAV:privilege element - multiple child elements?

Hi,
RFC3744 defines DAV:privilege as:

<!ELEMENT privilege ANY>

"ANY" technically implies one or more child elements. However, all
examples in 3744 have just a single child. It has been my assumption
that only one child is allowed. However, I recently came across a server
that is returning multiple child elements. So what is, or is not,
allowed here?

--
Cyrus Daboo

(Continue reading)

Werner Donné | 7 Jun 2010 17:11

Re: WebDAv collection sync: last issue

Hi,

I don't see why Depth:infinity should be ruled out from the start. You can let the server decide if the
performance penalty is too high or not. A server with a relational system underneath it, for example, can
do this with one query.

I don't agree with the "bubble up" principle. A collection changes when its member set changes. Changing a
resource that is referred to by one of the members doesn't affect the collection, whether that resource is
a collection or not. I think the "bubble up" principal is not consistent with the "getlastmodified"
property. It is also not needed if Depth:infinity is supported.

Best regards,

Werner.

On 07 Jun 2010, at 15:57, Cyrus Daboo wrote:

> Hi folks,
> The latest WebDAV collection sync draft is here:
<https://datatracker.ietf.org/doc/draft-daboo-webdav-sync/>. We believe we are close to done with
this and would like to submit to the IESG soon. However, there is one open issue that we need feedback from
implementors on.
> 
> The question is whether collection resources that are immediate children of the collection being
targeted for the REPORT should be reported as "modified" if any of their child resources (depth infinity)
are modified.
> 
> Key points:
> 
> 1) We have deliberately scoped the REPORT defined in this draft to be Depth:1 only - i.e. it will only report
(Continue reading)

Julian Reschke | 8 Jun 2010 14:35
Picon
Picon

Re: DAV:privilege element - multiple child elements?

On 07.06.2010 17:18, Weber, Heiko wrote:
> How about creating XML Schemas for all WebDAV XML response and request
> documents, so that it is really clear what is meant? We have created
> such XML schemas for at least some of the documents when we implemented
> the WebDAV support in the Tamino XML Server and can share these, if
> there is some place where they could be put...
> ...

Well, we have a DTD and it didn't help.

Sometimes a schema language can't express all the constraints properly.

So, can XML Schema define a thing like "must have a single child 
element, but the element name doesn't matter"?

Best regards, Julian

Julian Reschke | 8 Jun 2010 15:51
Picon
Picon

Re: DAV:privilege element - multiple child elements?

On 08.06.2010 15:43, Werner Donné wrote:
> It is not possible with XML Schema, but it is with Relax NG:
>
> http://www.relaxng.org/tutorial-20011203.html#IDAFLZR
>
> Best regards,
>
> Werner.

Not really a surprise.

If we ever rewrite these specs, I'm going to propose to use RelaxNG 
(compact notation), because of expressiveness and also readability.

Best regards, Julian

Werner Donné | 8 Jun 2010 15:43

Re: DAV:privilege element - multiple child elements?

It is not possible with XML Schema, but it is with Relax NG:

http://www.relaxng.org/tutorial-20011203.html#IDAFLZR

Best regards,

Werner.

On 08 Jun 2010, at 14:35, Julian Reschke wrote:

> On 07.06.2010 17:18, Weber, Heiko wrote:
>> How about creating XML Schemas for all WebDAV XML response and request
>> documents, so that it is really clear what is meant? We have created
>> such XML schemas for at least some of the documents when we implemented
>> the WebDAV support in the Tamino XML Server and can share these, if
>> there is some place where they could be put...
>> ...
> 
> Well, we have a DTD and it didn't help.
> 
> Sometimes a schema language can't express all the constraints properly.
> 
> So, can XML Schema define a thing like "must have a single child element, but the element name doesn't matter"?
> 
> Best regards, Julian
> 

--
http://www.pincette.biz/
Handling your documents with care, wherever you are.
(Continue reading)


Gmane