OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


By the way, I wouldn't mind if +v had a well-known mapping to
+version/numeric, so the following would be equivalent

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

Dave

-----Original Message-----
From: Dave McAlpin [mailto:dave.mcalpin@epokinc.com] 
Sent: Tuesday, April 29, 2003 4:43 PM
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:40Z)


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.. 







[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]