Re: The version element and workspaces

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: werner.donne@re.be

Received on Thursday, 30 March 2006 11:50:37 UTC