RE: LABEL request only allows one set, one add...

RFC2518 already established that validating parsers cannot strictly use the
DTD in the specification but must allow unknown elements in any element.

If RFC3253 consistently followed what you suggest, then auto-version would
also take a value "ANY" rather than being defined properly.

  <!ELEMENT auto-version (checkout-checkin | checkout-unlocked-checkin
     | checkout | locked-checkout)? >

RFC3253 has many such "restrictive" DTDs.

Lisa

> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Saturday, June 15, 2002 3:28 PM
> To: 'DeltaV (E-mail)'
> Subject: RE: LABEL request only allows one set, one add...
>
>
>
> Yes, in RFC3253, "at most one x, y, or z" is (x | y | z).
> If you were allowed to have an x and a y and a z, it uses
> and "and", e.g.: "at most one x, at most one y, and at most
> one z".  So you can do an add, a set, or a remove, but not
> more than one in the same request.  The "sequence of elements"
> is just there for extensibility.
>
> RFC-3253 has no restrictive DTD statements such as:
>  <!ELEMENT label (add | set | remove)>
> since if this DTD was used by a validating parser,
> it would violate WebDAV semantics, which requires that
> unknown element types be ignored, and not cause a parse
> error.
>
> Cheers,
> Geoff
>
> -----Original Message-----
> From: Lisa Dusseault [mailto:ldusseault@xythos.com]
> Sent: Saturday, June 15, 2002 10:10 AM
> To: 'Clemm, Geoff'; 'DeltaV (E-mail)'
> Subject: RE: LABEL request only allows one set, one add...
>
>
> That's a great point, but it makes me realize I may be reading the
> definition wrong.  I had assumed it to be possible to add one
> label, remove
> a second and set a third, all in the same request. This
> assumption was based
> on the following language:
>
>      The request body MUST be a DAV:label element.
>
>       <!ELEMENT label ANY>
>       ANY value: A sequence of elements with at most one DAV:add,
>       DAV:set, or DAV:remove element.
>
> Perhaps this is supposed to mean that only one child element
> can be inside
> label, but "a sequence" does imply more than one.  If you
> mean to restrict
> it to one only, then the definition should be:
>
> 	<!ELEMENT label (add | set | remove)>
>
> Lisa
>
> > -----Original Message-----
> > From: ietf-dav-versioning-request@w3.org
> > [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Clemm, Geoff
> > Sent: Friday, June 14, 2002 8:24 PM
> > To: DeltaV (E-mail)
> > Subject: RE: LABEL request only allows one set, one add...
> >
> >
> >
> > I wouldn't say it was an oversight, but rather a use
> > case that wasn't sufficiently common to warrant making
> > the protocol more complicated to support it.
> > In particular, you would have to define the semantics
> > of what would happen if one part of the request would fail
> > and the other would succeed, and how to marshall that
> > error information.
> >
> > Cheers,
> > Geoff
> >
> > -----Original Message-----
> > From: Lisa Dusseault [mailto:ldusseault@xythos.com]
> > Sent: Friday, June 14, 2002 9:31 PM
> > To: DeltaV (E-mail)
> > Subject: LABEL request only allows one set, one add...
> >
> >
> >
> >
> > Is it an oversight that the LABEL request only allows one
> > set, one add, or
> > one remove at a time (or one of each, but not two of any?)
> >
> > For example, say I wanted to add <label-name>foo</label-name> and
> > <label-name>bar</label-name> to a version in one request.
> > The definition of
> > the LABEL request body is:
> >
> >   <!ELEMENT label ANY>
> >   ANY value: A sequence of elements with at most one
> >   DAV:add, DAV:set, or DAV:remove element.
> >
> >   <!ELEMENT add (label-name)>
> >   <!ELEMENT set (label-name)>
> >   <!ELEMENT remove (label-name)>
> >
> >   <!ELEMENT label-name (#PCDATA)> PCDATA value: string
> >
> > Since <add> can only contain one label-name, only one label
> > can be added per
> > each request.  I would have to issue two LABEL requests to
> > add both foo and
> > bar labels.
> >
> > Lisa
> >
>

Received on Saturday, 15 June 2002 19:48:37 UTC