No Subject

In particular when it comes to synchronization of data identified with
XRIs (which will be a major feature of the XDI work ahead), version
metadata is simple essential. Which I think may illustrate why there may
be a difference between the importance of version syntax in XRIs vs. the
TAG conclusion re versioning in URIs in general.

I understand the TAG's position as I agree that iw would be very
difficult if not impossible to standardize a syntax for all versioning,
period. There are simply too many approaches. It would be a little like
trying to cram all features of all word processors and desktop
publishing systems everywhere into HTML. Forget it, it's too big a job.

So instead HTML applied the 80/20 rule and just included the basic text
formats that were used in the vast majority of documents - heads,
bulleted lists, numbered lists, etc. And by creating a simple standard
markup language that included these most common text formatting
features, look at the incredible impact HTML had.

So I would submit that by doing the same for version metadata in
identifiers, i.e., applying the 80/20 rule and providing a basic syntax
for versioning with a few widely used defaults formats (datetime,
numberpath, and textpath), we can do for the broad usefulness of XRIs
what HTML did for the broad usefulness of the Web. (And of course by
making this versioning syntax extensible, we'll get the advantages of
XML over HTML right from the start.)

=3DDrummond=20

-----Original Message-----
From: Peter C Davis [mailto:peter.davis@neustar.biz]
Sent: Tuesday, April 22, 2003 1:02 PM
To: Lindelsee, Mike
Cc: 'xri@lists.oasis-open.org'
Subject: Re: [xri] TAG discussion of versioning in URIs

I think i can agree with this.  esentially profile out [:version], such
that resolvers MAY ignore such things (of course, interpreting XRI
equivalence w/out [:version] may cause headaches).

--- peterd

Lindelsee, Mike wrote:

>I can think of applications where versioning would be a nice feature.
I must say though that this would not be a compelling feature for the
vast majority of development/architecture work I've done in the past.
My recommendation is that versioning not be considered part of the
"core" XRI spec, but be added in as a profile/module/conformance level
feature.
>
>Mike
>
>=20
>
>>-----Original Message-----
>>From: Wachob, Gabe [mailto:gwachob@visa.com]
>>Sent: Tuesday, April 22, 2003 12:25 PM
>>To: 'xri@lists.oasis-open.org'
>>Subject: RE: [xri] TAG discussion of versioning in URIs
>>
>>
>>I really like the XRI-cross-reference-as-version-tag, but I
>>think it conflicts with the human usability aspect (drummond?
>>dave mcalpin? I think this is more important a concern to them).
>>
>>I tend to agree with you that providing a syntax for versions
>>doesn't import the complexity inherent in using and
>>interpreting those versions.
>>
>>Does anybody else have opinions on the threshold question of
>>whether or not to support version syntax, in general?
>>
>>      -Gabe
>>
>>  =20
>>
>>>-----Original Message-----
>>>From: Peter C Davis [mailto:peter.davis@neustar.biz]
>>>Sent: Tuesday, April 22, 2003 7:49 AM
>>>To: 'xri@lists.oasis-open.org'
>>>Subject: Re: [xri] TAG discussion of versioning in URIs
>>>
>>>
>>>Wachob, Gabe wrote:
>>>
>>>    =20
>>>
>>>>I'm not sure there's been a lot of discussion (relative to a
>>>>      =20
>>>>
>>>lot of other topics) about versioning, but there seems to be
>>>a consensus among those on the TAG that versioning of URIs is
>>>a nonstarter. I'm not sure that they've really explained the
>>>issue with versioning besides to say "its complicated". I
>>>happen to agree that the interpretation of versions can be
>>>complicated, but I am not sure if we are going to deal with
>>>that complication here or whether it becomes an application
>>>issue (for applications using versioned XRIs).
>>>    =20
>>>
>>>>
>>>>
>>>>      =20
>>>>
>>>While i agree with TBL that versioning is complicated, it
>>>    =20
>>>
>>is only so
>>  =20
>>
>>>when one attempts to apply "meaning" to the version
>>>identifier.  I think
>>>this IS an application/implimentation issue, best left out of
>>>scope for
>>>XRI.  Simply providing a means to express versions within the
>>>structure
>>>should be our aim, not detailed normative text attempting to
>>>sovle the
>>>problem.
>>>
>>>In fact, now that i think about it, the version string could
>>>be an XRI
>>>itself, resolving to the specification of the versioning notation
>>>employed for this instance of the resource, as well as the version
>>>identifier (whatever that is is determined by the version
>>>sepcification
>>>itself). Continuing the "host version" thread:
>>>
>>>  =20
>>>    =20
>>>
>>host[@urn:dns:versionspec:serial:2002030415].foo.biz/this/resource
>>  =20
>>
>>>(@ was arbitrary on my part.... versioning specifications may
>>>have IPR
>>>attached to them??).
>>>So dereferencing urn:dns:versionspec:serial provides the
>>>    =20
>>>
>>semantics of
>>  =20
>>
>>>"things to the right"...
>>>
>>>--- peterd
>>>
>>>    =20
>>>