I have added the obvious "Version:" field for symetry with
Content-Type: and Language: which are all now variant specifiers.
I have also added "Derived from" which is necessary to keep
track of parallel modifications a la CVS/RCS/SCCS/CMS etc.
I append some cut and splurdge from the spec.
Tim Berners-Lee
______________________________________________________________
This gives a URI with which the object may be found. There is no
guarantee that the object can be retrieved using the URI specified.
However, it is guaranteed that if an object is successfully retrieved
using that URI it will be to a certain given degree the same object
as this one.
If the URI is used to refer to a set of variants, then the dimensiosn
in which the variants may differ must be given with the "vary"
parameter:
Syntax URI: <uri> [ vary = dimension [ , dimension
]* ]
dimension content-type | language | version
If no "vary" parameters are given, then the URI may not return
anything other than the same bit stream as this object.
Multiple occurencies of this field give alternative access names or
addresses for the object.
Examples
URI: http://info.cern.ch/pub/www/doc/url6.multi
vary=content-type
This indicates that retrieval given the URI will return the same
document, never an updated version, but optionally in a different
rendition.
URI: http://info.cern.ch/pub/www/doc/url.multi
vary=content-type, language, version
This indicates that the URI will return the smae document, possibly
in a different rendition, possibly updated, and without excluding the
provision of translations into different languages.
URI: http://info.cern.ch/pub/www/doc/url6.ps
vary=content-type
This indicates that accessing the URI in question will return exactly
the same bitstream.
______________________________________________________________[...]
Version:
This is a string defining the version of an evolving object.
Its format is currently undefined, and so it should be treated as
opaque to the reader, defined by the informatiuon provider. The
version field is used to indicate evolution along a single path of a
partucular work. It is NOT used to indicate derived works (use a
link), translations, or renditions in different representations.
Note: It would be useful to have sufficient semantics to be able to
deduce whether one version predated or postdated another. However,
it may also be useful to be able to insert a particular local code
management system's own version stamp in this field. Typically,
publishers will have quite complex version information containing
hidden local semantics, giving value to the idea of this field being
opaque to other readers ofthe document.
Derived-From:
When an editied object is resubmitted using PUT for example, this
field gives the value of the Version . This typically allows a server
to check for example that two concurrent modifications by different
parties will not be lost, and for example to use established version
management techniques to merge both modifications.