Fw: Discussion Topic: Simple Version Selection and Checkout
Sankar Virdhagriswaran (sv@crystaliz.com)
Sat, 30 Jan 1999 20:56:34 -0500
Message-ID: <005201be4cbc$f3cb4460$944406d1@honey-bee>
From: "Sankar Virdhagriswaran" <sv@crystaliz.com>
To: <ietf-dav-versioning@w3.org>
Date: Sat, 30 Jan 1999 20:56:34 -0500
Subject: Fw: Discussion Topic: Simple Version Selection and Checkout
this mail bounced because of wrong Cc: address...
-----Original Message-----
From: Sankar Virdhagriswaran <sv@crystaliz.com>
To: jamsden@us.ibm.com <jamsden@us.ibm.com>
Cc: ietf-dav-versioning@w3c.org <ietf-dav-versioning@w3c.org>
Date: Saturday, January 30, 1999 8:26 PM
Subject: Re: Discussion Topic: Simple Version Selection and Checkout
>Jim, Geoff
>
>Let me take this note to answer a couple of points and to make a broader
>point.
>
>>What other "manual" selection are you suggesting that would not involve
>>something like labels. A URI is a name of a resource. A label is just a
>>name of a particular revision of that resource.
>>
>
>It appears that you and Geoff are actually in disagreement about the above
>statement (correct me if I am wrong). Anyhow, I have a specific use case
>point and a broader architecture point.
>
>1) Architecture point
>
>Let me start with the architecture point. Configurations, IMHO, define an
>alternate namespace. The objects associated with the names could be 'bound'
>using a one to one mapping between names and objects and using a selection
>rule based on attributes of the object. The labeling scheme I thought was
>the second kind and the explicit naming as seen in traditional version
>control system I thought was the first kind. I would like to see the
>architecture of the configuration namespace mechanism to be similar to
other
>namespace mechanisms inside DAV and outside so that one could leverage
>implementations and implementation experience. In particular, if you look
at
>the ADSI spec. from Microsoft or JNDI spec. from Javasoft, they provide two
>ways of resolving names to objects - explicit naming and selection by
>attribute. The collection mechanism in DAV (should) also provides similar
>mechanisms. If our scheme is similar in nature, we could use leverage
>implementations and expertise across different types of namespaces, but
>using the same type of framework.
>
>The above is not a protocol point, but I thought I should make it so that
>server implementations are made easier. While one has to implement
different
>namespace service providers for collections, configurations, documents,
>etc., using a consistent scheme helps reduce the work involved and
certainly
>the training involved.
>
>2) Use case point
>
>>Setting labels should not be an administrative activity. The should be set
>>by the editor of the resource to say something about the meaning of the
>>revision.
>
>In either case, there is an administrative overhead that many of the web
>site authors (particularly from the 'media' side of the world) are not used
>to doing.
>
>More importantly, in authoring documents, it makes it much easier if
>explicit names are used to do link checking and deployment. I have sense
>that you folks think of a configuration or workspace in the software
>development sense of the word. One could think of an HTML document itself
as
>a configuration. In this case, an author will not typically be referring to
>(i.e., linking to) multiple versions of the same document. The author would
>like to refer to a linked document with an explicit URL reference. In this
>kind of authoring mode, selecting a URL of a linked document using labels
is
>foreign to the author and more importantly to the authoring tool.
>
>I am making several points here:
>
>a) That document authors would prefer to use direct and explicit references
>( use case style point), and
>
>b) Tools such as link checkers and deployers can deal with explicit
>references much more easily than resolved names based on attributes (i.e.,
>labels)
>
>c) If one were to consider an HTML (or XML + XML Link) document itself as a
>configuration, then label based selection involves cooperation by authoring
>clients. I believe that this would be harder to achieve as compared to
>browsers/DAV clients providing the same functionality.
>
>Does this all make sense to you folks?
>
>Bottom line: I am arguing for providing explicit names and attribute based
>selection. I am also arguing that the specification of this part of the
>protocol should be similar to DAV collections and other namespace/directory
>mechanisms out there.
>
>
>
>
>
>
>
>
>
>
>
>