The version element and workspaces

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

The version element and workspaces

Werner Donné

Hi,

Is there a definition of that element, or any other? There doesn't
seem to be a section "XML Element Definitions" as in RFC 2518.

In a workspace the VERSION-CONTROL method can indicate a version
of an existing version history. When the "label" feature is also
supported the method could have additional semantics, where a label-name
element may be added to the version element and where the href element
could then refer to a version history or a VCR that is connected to
that version history.

Regards,

Werner.
--
Werner Donné  --  Re
Engelbeekstraat 8
B-3300 Tienen
tel: (+32) 486 425803 e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: The version element and workspaces

Manfred Baedke

Hi Werner,

this would indeed be useful, especially since a similar semantics exists
for CHECKOUT applied to versions.

Regards,
Manfred

Werner Donné wrote:

> Hi,
>
> Is there a definition of that element, or any other? There doesn't
> seem to be a section "XML Element Definitions" as in RFC 2518.
>
> In a workspace the VERSION-CONTROL method can indicate a version
> of an existing version history. When the "label" feature is also
> supported the method could have additional semantics, where a label-name
> element may be added to the version element and where the href element
> could then refer to a version history or a VCR that is connected to
> that version history.
>
> Regards,
>
> Werner.
>  


Reply | Threaded
Open this post in threaded view
|

Re: The version element and workspaces

Geoffrey M Clemm
In reply to this post by Werner Donné


Werner wrote on 03/27/2006 06:14:10 AM:
> Is there a definition of that element, or any other? There doesn't
> seem to be a section "XML Element Definitions" as in RFC 2518.


The XML elements that appear in the body of a method are defined
in the section of the specification that defines that method.
The XML elements that are the value of a property are defined in
the section of the specification that defines that property.

> In a workspace the VERSION-CONTROL method can indicate a version
> of an existing version history.


The variant of the VERSION-CONTROL method that
allows a version to be specified to create a VCR for an existing
version-history is defined in section 6.7. So the definition of
the version xml element appears there:
 
     <!ELEMENT version (href)>

An example of this is element is found in section 6.7.1.

     VERSION-CONTROL /ws/public/bar.html HTTP/1.1
     Host: www.webdav.org
     Content-Type: text/xml; charset="utf-8"
     Content-Length: xxxx

     <?xml version="1.0" encoding="utf-8" ?>
     <D:version-control xmlns:D="DAV:">
       <D:version>
         <D:href>http://repo.webdav.org/his/12/ver/V3</D:href>
       </D:version>
     </D:version-control>

> When the "label" feature is also
> supported the method could have additional semantics, where a label-name
> element may be added to the version element and where the href element
> could then refer to a version history or a VCR that is connected to
> that version history.


Yes, it logically could, but this is not defined in RFC 3253.

Cheers,
Geoff

Reply | Threaded
Open this post in threaded view
|

Re: The version element and workspaces

Werner Donné

> The XML elements that appear in the body of a method are defined
> in the section of the specification that defines that method.

Indeed, but this implies that elements which are used in more than
one method are specified more than once, e.g. fork-ok.

>> When the "label" feature is also
>> supported the method could have additional semantics, where a label-name
>> element may be added to the version element and where the href element
>> could then refer to a version history or a VCR that is connected to
>> that version history.
>
> Yes, it logically could, but this is not defined in RFC 3253.

Any chance this might change in the future?

> Cheers,
> Geoff

Regards,

Werner.
--
Werner Donné  --  Re
Engelbeekstraat 8
B-3300 Tienen
tel: (+32) 486 425803 e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: The version element and workspaces

Geoffrey M Clemm

Werner wrote on 03/30/2006 12:14:00 PM:
>
> > The XML elements that appear in the body of a method are defined
> > in the section of the specification that defines that method.
>
> Indeed, but this implies that elements which are used in more than
> one method are specified more than once, e.g. fork-ok.


Yes, we decided that people would rather be able to see the definitions
where they are used, rather than having to scroll back to an appendix.
We also could identify no compelling reason to duplicate the definitions
in an appendix, so we did not do so.

> >> When the "label" feature is also
> >> supported the method could have additional semantics, where a label-name
> >> element may be added to the version element and where the href element
> >> could then refer to a version history or a VCR that is connected to
> >> that version history.
> >
> > Yes, it logically could, but this is not defined in RFC 3253.
>
> Any chance this might change in the future?


One would need to identify a significant interoperability or performance
problem in order for it to merit a revision to the specification.  
I don't think either would apply to this extension.


Cheers,
Geoff


Reply | Threaded
Open this post in threaded view
|

Re: The version element and workspaces

Werner Donné

Geoffrey M Clemm wrote:

>
> Werner wrote on 03/30/2006 12:14:00 PM:
>>
>> > The XML elements that appear in the body of a method are defined
>> > in the section of the specification that defines that method.
>>
>> Indeed, but this implies that elements which are used in more than
>> one method are specified more than once, e.g. fork-ok.
>
> Yes, we decided that people would rather be able to see the definitions
> where they are used, rather than having to scroll back to an appendix.
> We also could identify no compelling reason to duplicate the definitions
> in an appendix, so we did not do so.

Now you don't have to scroll elsewhere for the elements, but you have to
for the properties. I'm not suggesting any duplication. On the contrary,
the definitions could be centralised with hyperlinks to them wherever
they are used.

>
>> >> When the "label" feature is also
>> >> supported the method could have additional semantics, where a
> label-name
>> >> element may be added to the version element and where the href element
>> >> could then refer to a version history or a VCR that is connected to
>> >> that version history.
>> >
>> > Yes, it logically could, but this is not defined in RFC 3253.
>>
>> Any chance this might change in the future?
>
> One would need to identify a significant interoperability or performance
> problem in order for it to merit a revision to the specification.  
> I don't think either would apply to this extension.

Neither interoperability nor performance have anything to do with it. The
proposed extension doesn't break anything and if using a label in this
context could present a performance problem, then it would too in the
contexts where it is used now. It is only a matter of consistency. When
the label feature is supported, labels can be used for version selection
when a VCR is given, only not in all situations, for which I see no reason.

The use-case for workspaces is also very valid. When activities are supported
and used for branching, it is common to define the start of a new branch
based on a label instead of a physical version. Otherwise you can forget
about more advanced configuration management practices.

Why would interoperability and performance problems be the only reason for
a revision? This implies that the current feature set should be considered
as perfect, because how did the current features make it into the specification
then? How does the revision process work?

Performance is a non-issue. There is nothing shocking in WedDAV that would
cause performance problems by definition and I don't see why additions would.
The implementation should be sofisticated enough or simply not implement a
feature.

I agree that an extension shouldn't break interoperability, unless in a
major upgrade. Note, however, that this is not the same as requiring
that most existing implementations are able to implement it, because that
would mean the specification is not leading but merely consolidating an
existing state of affairs. WebDAV deserves to be more than window dressing
of existing products.

> Cheers,
> Geoff

Regards,

Werner.
--
Werner Donné  --  Re
Engelbeekstraat 8
B-3300 Tienen
tel: (+32) 486 425803 e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: The version element and workspaces

Geoffrey M Clemm

Any new addition to the specification will cause any client that uses
that addition to fail against older servers that were implemented
before that addition was defined.  To avoid this kind of failure,
we do not introduce changes in revisions of the specification unless
the benefit provided by that feature outweighs the cost of those failures.

Cheers,
Geoff

Werner Donné <[hidden email]> wrote on 03/31/2006 06:50:00 AM:
> Geoffrey M Clemm wrote:
> > One would need to identify a significant interoperability or performance
> > problem in order for it to merit a revision to the specification.  
> > I don't think either would apply to this extension.
>
> Neither interoperability nor performance have anything to do with it. The
> proposed extension doesn't break anything and if using a label in this
> context could present a performance problem, then it would too in the
> contexts where it is used now. It is only a matter of consistency. When
> the label feature is supported, labels can be used for version selection
> when a VCR is given, only not in all situations, for which I see no reason.
>
> The use-case for workspaces is also very valid. When activities are supported
> and used for branching, it is common to define the start of a new branch
> based on a label instead of a physical version. Otherwise you can forget
> about more advanced configuration management practices.
>
> Why would interoperability and performance problems be the only reason for
> a revision? This implies that the current feature set should be considered
> as perfect, because how did the current features make it into the
> specification
> then? How does the revision process work?
>
> Performance is a non-issue. There is nothing shocking in WedDAV that would
> cause performance problems by definition and I don't see why additions would.
> The implementation should be sofisticated enough or simply not implement a
> feature.
>
> I agree that an extension shouldn't break interoperability, unless in a
> major upgrade. Note, however, that this is not the same as requiring
> that most existing implementations are able to implement it, because that
> would mean the specification is not leading but merely consolidating an
> existing state of affairs. WebDAV deserves to be more than window dressing
> of existing products.

Reply | Threaded
Open this post in threaded view
|

Re: The version element and workspaces

Werner Donné

If new clients should work with older servers there should be
a mechanism for a client to detect the compliance level of the
server. It can then act accordingly. In RFC 2518 the DAV header
seems to be used for this. I don't find such a mechanism in
RFC 3253.

Regards,

Werner.

Geoffrey M Clemm wrote:

>
> Any new addition to the specification will cause any client that uses
> that addition to fail against older servers that were implemented
> before that addition was defined.  To avoid this kind of failure,
> we do not introduce changes in revisions of the specification unless
> the benefit provided by that feature outweighs the cost of those failures.
>
> Cheers,
> Geoff
>
> Werner Donné <[hidden email]> wrote on 03/31/2006 06:50:00 AM:
>> Geoffrey M Clemm wrote:
>> > One would need to identify a significant interoperability or performance
>> > problem in order for it to merit a revision to the specification.  
>> > I don't think either would apply to this extension.
>>
>> Neither interoperability nor performance have anything to do with it. The
>> proposed extension doesn't break anything and if using a label in this
>> context could present a performance problem, then it would too in the
>> contexts where it is used now. It is only a matter of consistency. When
>> the label feature is supported, labels can be used for version selection
>> when a VCR is given, only not in all situations, for which I see no
> reason.
>>
>> The use-case for workspaces is also very valid. When activities are
> supported
>> and used for branching, it is common to define the start of a new branch
>> based on a label instead of a physical version. Otherwise you can forget
>> about more advanced configuration management practices.
>>
>> Why would interoperability and performance problems be the only reason for
>> a revision? This implies that the current feature set should be considered
>> as perfect, because how did the current features make it into the
>> specification
>> then? How does the revision process work?
>>
>> Performance is a non-issue. There is nothing shocking in WedDAV that would
>> cause performance problems by definition and I don't see why additions
> would.
>> The implementation should be sofisticated enough or simply not implement a
>> feature.
>>
>> I agree that an extension shouldn't break interoperability, unless in a
>> major upgrade. Note, however, that this is not the same as requiring
>> that most existing implementations are able to implement it, because that
>> would mean the specification is not leading but merely consolidating an
>> existing state of affairs. WebDAV deserves to be more than window dressing
>> of existing products.
>

--
Werner Donné  --  Re
Engelbeekstraat 8
B-3300 Tienen
tel: (+32) 486 425803 e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: The version element and workspaces

Julian Reschke

Werner Donné wrote:
> If new clients should work with older servers there should be
> a mechanism for a client to detect the compliance level of the
> server. It can then act accordingly. In RFC 2518 the DAV header
> seems to be used for this. I don't find such a mechanism in
> RFC 3253.

Well, the mechanism would be the same.

The major question here is whether there's a group of implementors who
want that feature. In which case the right thing to do is to define an
extension (including the aforementioned discovery mechanism), and
publish it in an Internet Draft. If that gets traction, you may be able
to get it published as RFC through either the RFC Editor or the IESG.
If, at a future date, RFC3253 gets revised, the authors then will
certainly consider extensions that have been published since for
inclusion into the base protocol.

Sounds complicated? Yes. Consider it a way to prevent feature creep :-)

Best regards, Julian

Reply | Threaded
Open this post in threaded view
|

Re: The version element and workspaces

Manfred Baedke
In reply to this post by Werner Donné
Slightly OT: The DAV-compliance level as defined in RFC2518 is not of much use, since it does not offer much granularity. In real life, a server is able to support a feature or it is not, and since a server should try to support as many features as possible, any combination of supported features might occur at the end of the day. So the additional resource properties as defined in RFC3253 section 3.1 make more sense.

Regards,
Manfred

Werner Donné wrote:
If new clients should work with older servers there should be
a mechanism for a client to detect the compliance level of the
server. It can then act accordingly. In RFC 2518 the DAV header
seems to be used for this. I don't find such a mechanism in
RFC 3253.

Regards,

Werner.

Geoffrey M Clemm wrote:
  
Any new addition to the specification will cause any client that uses
that addition to fail against older servers that were implemented
before that addition was defined.  To avoid this kind of failure,
we do not introduce changes in revisions of the specification unless
the benefit provided by that feature outweighs the cost of those failures.

Cheers,
Geoff

Werner Donné [hidden email] wrote on 03/31/2006 06:50:00 AM:
    
Geoffrey M Clemm wrote:
      
One would need to identify a significant interoperability or performance
problem in order for it to merit a revision to the specification.  
I don't think either would apply to this extension.
        
Neither interoperability nor performance have anything to do with it. The
proposed extension doesn't break anything and if using a label in this
context could present a performance problem, then it would too in the
contexts where it is used now. It is only a matter of consistency. When
the label feature is supported, labels can be used for version selection
when a VCR is given, only not in all situations, for which I see no
      
reason.
    
The use-case for workspaces is also very valid. When activities are
      
supported
    
and used for branching, it is common to define the start of a new branch
based on a label instead of a physical version. Otherwise you can forget
about more advanced configuration management practices.

Why would interoperability and performance problems be the only reason for
a revision? This implies that the current feature set should be considered
as perfect, because how did the current features make it into the
specification
then? How does the revision process work?

Performance is a non-issue. There is nothing shocking in WedDAV that would
cause performance problems by definition and I don't see why additions
      
would.
    
The implementation should be sofisticated enough or simply not implement a
feature.

I agree that an extension shouldn't break interoperability, unless in a
major upgrade. Note, however, that this is not the same as requiring
that most existing implementations are able to implement it, because that
would mean the specification is not leading but merely consolidating an
existing state of affairs. WebDAV deserves to be more than window dressing
of existing products.