ACL: DAV:privilege element - multiple child elements?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

ACL: DAV:privilege element - multiple child elements?

Cyrus Daboo-2
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


Reply | Threaded
Open this post in threaded view
|

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

Julian Reschke
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



Reply | Threaded
Open this post in threaded view
|

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

Cyrus Daboo-2
Hi Julian,

--On June 7, 2010 4:10:00 PM +0200 Julian Reschke <[hidden email]>
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


Reply | Threaded
Open this post in threaded view
|

RE: DAV:privilege element - multiple child elements?

Weber, Heiko
In reply to this post by Cyrus Daboo-2
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: [hidden email] [mailto:[hidden email]]
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




Reply | Threaded
Open this post in threaded view
|

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

Julian Reschke
In reply to this post by Cyrus Daboo-2
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 -->

?

In particular, you wrote you saw the "other" behaviour in the wild. Are
the developers aware of this issue, or even on this list? Are they
willing to change their implementation?


Best regards, Julian


Reply | Threaded
Open this post in threaded view
|

Re: DAV:privilege element - multiple child elements?

Julian Reschke
In reply to this post by Weber, Heiko
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

Reply | Threaded
Open this post in threaded view
|

Re: DAV:privilege element - multiple child elements?

Werner Donné-2
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.


Reply | Threaded
Open this post in threaded view
|

Re: DAV:privilege element - multiple child elements?

Julian Reschke
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

Reply | Threaded
Open this post in threaded view
|

RE: DAV:privilege element - multiple child elements?

Weber, Heiko

At the end of this mail is the XML Schema which we have been using for
ACLs. I'm not claiming that it is complete, but this schema does limit
the number of elements below the DAV:privilege to one and allows any
element, but it does not restict the usage of attributes or sub
elements.

If we allow user defined elements, why do we then want to limit it to be
an element without attributes and sub elements though?

If all we are interested in is the QName of the element it would make
much more sense to simply put an attribute into the DAV:privilege
element containing the QName of the privilege. Ok, that was modeled
differently historically, so possibly we just have to live with that.

best regards,
   Heiko Weber

----

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="DAV:" attributeFormDefault="qualified"
elementFormDefault="qualified" xmlns:DAV="DAV:"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="acl">
    <xs:complexType>
      <xs:sequence minOccurs="0" maxOccurs="unbounded">
        <xs:element name="ace">
          <xs:complexType>
            <xs:sequence>
              <xs:choice>
                <xs:element ref="DAV:principal"></xs:element>
                <xs:element name="invert">
                  <xs:complexType>
                    <xs:sequence>
                      <xs:element ref="DAV:principal"></xs:element>
                    </xs:sequence>
                  </xs:complexType>
                </xs:element>
              </xs:choice>
              <xs:choice>
                <xs:element name="grant">
                  <xs:complexType>
                    <xs:sequence>
                      <xs:element ref="DAV:privilege"
maxOccurs="unbounded"></xs:element>
                    </xs:sequence>
                  </xs:complexType>
                </xs:element>
                <xs:element name="deny">
                  <xs:complexType>
                    <xs:sequence>
                      <xs:element ref="DAV:privilege"
maxOccurs="unbounded"></xs:element>
                    </xs:sequence>
                  </xs:complexType>
                </xs:element>
              </xs:choice>
              <xs:element name="protected" minOccurs="0">
                <xs:complexType></xs:complexType>
              </xs:element>
              <xs:element name="inherited" minOccurs="0">
                <xs:complexType>
                  <xs:sequence>
                    <xs:element ref="DAV:href"></xs:element>
                  </xs:sequence>
                </xs:complexType>
              </xs:element>
            </xs:sequence>
          </xs:complexType>
        </xs:element>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
  <xs:element name="href" type="xs:anyURI"></xs:element>
  <xs:element name="principal">
    <xs:complexType>
      <xs:choice>
        <xs:element ref="DAV:href"></xs:element>
        <xs:element name="all">
          <xs:complexType></xs:complexType>
        </xs:element>
        <xs:element name="authenticated">
          <xs:complexType></xs:complexType>
        </xs:element>
        <xs:element name="unauthenticated">
          <xs:complexType></xs:complexType>
        </xs:element>
        <xs:element name="property">
          <xs:complexType>
            <xs:sequence>
              <xs:any processContents="skip"></xs:any>
            </xs:sequence>
          </xs:complexType>
        </xs:element>
        <xs:element name="self">
          <xs:complexType></xs:complexType>
        </xs:element>
      </xs:choice>
    </xs:complexType>
  </xs:element>
  <xs:element name="privilege">
    <xs:complexType>
      <xs:sequence>
        <xs:any processContents="skip"></xs:any>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
</xs:schema>

Reply | Threaded
Open this post in threaded view
|

Re: DAV:privilege element - multiple child elements?

Julian Reschke
On 09.06.2010 12:06, Weber, Heiko wrote:
> ...
> If we allow user defined elements, why do we then want to limit it to be
> an element without attributes and sub elements though?
> ...

In general, it depends on the context. For instance, DAV:property can be
just a name (in the PROPFIND request), or contain stuff (in PROPPATCH,
and the PROPFIND result).

> ...
> If all we are interested in is the QName of the element it would make
> much more sense to simply put an attribute into the DAV:privilege
> element containing the QName of the privilege. Ok, that was modeled
> differently historically, so possibly we just have to live with that.
> ...

WebDAV mostly avoids attributes, and furthermore processing QNames in
content is very easy to get wrong; thus sticking with elements IMHO was
the right design decision.

Best regards, Julian