Thoughts on versioning

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

Sorry I've been out of the loop the last couple of days. For what it's
worth, here's my opinion about some of the questions about versioning that
have been floating around.

1) Isn't version information metadata that doesn't belong in an identifier?

In general, I don't think we should include syntax for metadata. But I'd
argue version information is a special case, mostly because it's _so_
common. Look at the URL for the document we're discussing

http://www.oasis-open.org/apps/org/workgroup/xri/download.php/1614/xri-unifi
ed-strawman-draft-05.pdf

We, like almost everyone else constructing URLs, invented our own ad hoc
version syntax. The fact that URLs don't provide a standard way to express
information about a resource that virtually everyone needs can't be
considered a good thing. We should fix that in XRIs.

2) Version information makes resolution difficult, makes caching
problematic, raises hard questions about canonicalization/equivalence etc.
Is it really worth it?

In this case, I don't think so. We're anticipating making a clear
distinction between the resolvable part and the local part of XRIs. Most of
the problems above go away if we don't allow versioning in the resolvable
part. While you can certainly imagine use cases where versioning the
resolvable portion's useful, I don't think we lose that much by limiting it
to the local part. If that turns out to be too restrictive, we can always
add it to the resolvable portion in a later version of the spec (when we
have a better understanding of the impact on resolution) without breaking
existing XRIs.

It's also worth pointing out that you don't see people working around this
in URLs. While it's very common to see something like

http://www.example.com/foo-v3

you normally don't see something like

http://www-v2.example.com/foo

3) What symbols should be used for version enclosure?

I don't have a strong opinion here. I agree with Drummond that users
normally won't be typing version stuff so we don't have the same
requirements about memorability, succinctness etc as we do in some other
parts of XRIs. I also agree that parens are confusing because they make
versions look like cross-references. I like square brackets but don't think
we should conflict with an existing RFC's reserved characters. For what it's
worth, XNS Addressing didn't use open/close characters, but instead used a ,
to introduce metadata and the next reserved character or end-of-line to
terminate it, like

xns://foo/bar/,v2

4) Is version info appropriate for XRI-URNs? Doesn't it break the "once and
forever" requirement?

In general I think we're ok, but it's a good question. RFC 1737 specifies
the requirement as

Persistence: It is intended that the lifetime of a URN be permanent.  That
is, the URN will be globally unique forever, and may well be used as a
reference to a resource well beyond the lifetime of the resource it
identifies or of any naming authority involved in the assignment of its
name.

I don't think version information breaks this, but it does introduce an
interesting point - two versions of a resource are in fact two different
resources. That's pretty obvious when version data's munged into the
resource name, but it's a little less clear when version data's separated
out into metadata looking stuff. That's ok, in my opinion, or at least it's
less problematic than having everyone make up their own syntax.

If that's true, though, date/time versions may introduce a complication.

urn:xri://.A4B7.14E8[:2].CA62

is ok, I think, because presumably there really is a version 2 of the
resource identified by .A4B7.14E8.

urn:xri://.A4B7.14E8[;2001-03-04T20:15:40Z].CA62

on the other hand, isn't nearly as clear. Is there a distinct virtual
resource for every instant in time? Does this virtual resource become a real
resource when it's referenced? I don't have any idea, but it seems like
date/time versions may need to be excluded from XRI-URNs, for sanity if
nothing else.

One other issue with respect to 1737. Version info, as we envision it, is
"semantically reflective". In other words, a URN with a version contains
visible information about the underlying resource. 1737 says in an ideal
world, a URN should be completely opaque and reflect nothing about the
resource it identifies. Except for a few special cases like UUIDs, though,
almost all URNs are semantically reflective to some degree. 1737 recognizes
this and says that URN designers should just take semantic reflection into
consideration, which is why I'm raising the issue here.

5) It's impossible to provide syntax for all possible version schemes.
Doesn't that mean we shouldn't do it?

It's easy to see why other groups have this problem. Drummond's comments
about the 80/20 rule are right, but the 20% who get left out are the ones
who make all the noise. Fortunately, cross-references provide a way out for
that 20%. Something like

xri://foo.example/bar/[(xri://example/version_spec/my_special_syntax)/1a2b]

isn't pretty and it's hard to imagine it being globally understandable, but
for the group of people who use "my_special_syntax" it works.

6) We can do all versioning with cross-refs. Why do we even need special
syntax?

For example, why couldn't the example in 5) just be expressed as

xri://foo.example/bar/(xri://example/version_spec/my_special_syntax)/1a2b

In my opinion, using a cross-reference as a processing instruction for the
nodes that follow is fine (though I know there are others who disagree) and
the above is clearly legal. But versioning is so ubiquitous that I'd still
ague it deserves special consideration in the syntax. Calling it out in the
syntax also allows a processor that doesn't keep track of versions to know
what to ignore. In the example above, there's no easy way to tell that the
last two nodes are ignorable.

Dave