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:firstname.lastname@example.org] Sent: Tuesday, April 29, 2003 4:43 PM To: 'Wachob, Gabe'; email@example.com 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:firstname.lastname@example.org] Sent: Tuesday, April 29, 2003 12:13 PM To: 'email@example.com' 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..