RE: [xri] cross-reference-based version proposal

["Dave McAlpin" <dave.mcalpin@epokinc.com>]

Right, but someone needs to specify the rules and semantics around the
+Version namespace. If the concept of version is going to be globally
understood for XRIs, I think we're the ones who need to do that spec.

Dave

-----Original Message-----
From: Sakimura, Nat [mailto:n-sakimura@nri.co.jp] 
Sent: Thursday, May 01, 2003 6:46 AM
To: Dave McAlpin; xri@lists.oasis-open.org
Subject: RE: [xri] cross-reference-based version proposal

I feel that whether we should go (+version/1.2) or (+version/numeric/2)
is more an implementation problem of +version object at the global
registry and not quite that of XRI syntax. Am I missing something? 

Nat

-----Original Message-----
From: Dave McAlpin [mailto:dave.mcalpin@epokinc.com] 
Sent: Wednesday, April 30, 2003 8:43 AM
To: 'Wachob, Gabe'; xri@lists.oasis-open.org
Subject: RE: [xri] cross-reference-based version proposal

Thanks for summarizing this Gabe. I'll just make comments on two of the
examples

xri://naming.authority/local/part/(+version/1.2)

It seems wrong to me that 1.2 is an immediate child of +version in that
it
pollutes a namespace we intend to use for version types. An example like
this might be better.

xri://naming.authority/local/part/(+version/numeric/2)

Also, the example

xri://naming.authority/local/part/(+version/date/01-03-03)

is confusing because it's not clear to the reader how the month/day/year
order is handled. An example that presents the date/time in a
well-defined,
standard form might be better

xri://naming.authority/local/part/(+version/datetime/2001-03-04T20:15:40
Z)


Dave

-----Original Message-----
From: Wachob, Gabe [mailto:gwachob@visa.com] 
Sent: Tuesday, April 29, 2003 12:13 PM
To: 'xri@lists.oasis-open.org'
Subject: [xri] cross-reference-based version proposal

XRI TCers-
	Several of us who are particularily interested in versions have
been
batting around ideas for a versioning mechanism that is general/flexible
yet
doesn't introduce complexity in the syntax.

	Apologies ahead of time to Dave McAlpin, Mike Lindelsee, and
Drummond if I'm not precisely presenting our consensus, but here's a
rough
description. 

	The proposal is that version tags in identifiers are simply
cross
references to a special global context namespace - ie +version (maybe
+ver
or +v). Thus, version 1.2 of 
xri://naming.authority/local/part 

is 
xri://naming.authority/local/part/(+version/1.2)

	And with this mechanism we can even specify version "types":

xri://naming.authority/local/part/(+version/cvs/1.2)
xri://naming.authority/local/part/(+version/date/01-03-03)

	Note that this is an interesting use of the global namespaces
and
cross references. From a syntactic point of view, the version tag is
just a
normal cross reference, so components not interested in versioning can
essentially ignore the fact that there is a version tag in the
identifier.
For components that are interested in knowing that a particular path
segment
is a version tag, it need only syntactically check the first 9
characters
(in the case of (+version) or 3 for (+v)). Note that versions CAN appear
anywhre in the dot-path (and perhaps in the naming authority part --
thats a
separate issue). 

	This proposal strikes us as a good compromise between syntax
regularity and ease-of-use. It "gets out of the way" in terms of
introducing
new syntactic structure for those who don't want to deal with
versioning,
and yet seems pretty easy to deal with for those who do. 

	Potential questions/issues:

1) is +version too verbose? what about +ver or +v

2) do we define a few version types under +version (ie +version/cvs
+version/datetime, etc)

3) this introduces what is essentially a "reserved XRI" in the XRI
specs.
This is something we haven't done yet. I don't have a problem with it,
but
we need to be aware that we are doing this. 


	-Gabe

P.S. I would note that the approach of using +concept cross-references
could
allow for embedding other featurs in XRIs such as "self-authenticating
identifiers" a la SGNP (ie where you put in a public key as part of the
name
so that all messages sent to the identifier can be encrypted for that
identifier). I'm not suggesting this is neccesarily a path we are
intending
to go down - merely that its a dimension of extensibility that might
easily
and cleany allow semantics to be layered on top of the base syntax..