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

Non-standard elements can certainly be added by a server to
any element (following RFC2518 extensibility rules), but 
our design principle for RFC3253 is to add new elements (e.g.
in later drafts of RFC3253) at the request/response body level,
rather than modifying any existing (non-top-level) elements.

This is just based on the request by some implementors to be
able to implement certain arguments and values as "booleans"
or "fixed length enumerated types), rather than leaving room
in the implementation for arbitrary future extensions at these
lower levels.

So nothing deep going on here, just an effort to minimize
rework of existing implementations when new protocol elements
are introduced.

Cheers,
Geoff  

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@greenbytes.de]
Sent: Sunday, June 16, 2002 1:28 PM
To: Clemm, Geoff; 'DeltaV (E-mail)'
Subject: 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 Wednesday, 31 July 2002 08:02:45 UTC