RFC3253 XML extensibility, was: LABEL request only allows one set, one add...

Geoff,

does this basically mean that, for instance, the auto-version property is
*not* meant to be extensible with new protocol elements?

As RFC3253 has no specific wording about what the DTD fragments mean, but
the DTD fragments *by definition* cannot be normative (for instance, because
of namespace requirements), I was under the impression that RFC2518's
extensibility rules apply to RFC3253 as well. Was I wrong?

Julian

> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Sunday, June 16, 2002 3:54 PM
> To: 'DeltaV (E-mail)'
> Subject: RE: LABEL request only allows one set, one add...
>
>
>
> Good point ... I should have been more specific.
>
> RFC-3253 uses "ANY" as the DTD for all method request
> and response bodies, as we believed that was where
> extensibility was most required, and so we wanted
> to emphasize this fact in the protocol.
>
> Properties and nested request/response elements
> within method request/response bodies are defined with
> the standard DTD's.
>
> Cheers,
> Geoff
>
> -----Original Message-----
> From: Lisa Dusseault [mailto:ldusseault@xythos.com]
> Sent: Saturday, June 15, 2002 7:49 PM
> To: 'Clemm, Geoff'; 'DeltaV (E-mail)'
> Subject: 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 Sunday, 16 June 2002 13:28:47 UTC