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] TAG discussion of versioning in URIs


Wachob, Gabe wrote:

>I'm not sure there's been a lot of discussion (relative to a 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). 
>
>  
>
While i agree with TBL that versioning is complicated, it is only so 
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:

    host[@urn:dns:versionspec:serial:2002030415].foo.biz/this/resource

(@ was arbitrary on my part.... versioning specifications may have IPR 
attached to them??).
So dereferencing urn:dns:versionspec:serial provides the semantics of 
"things to the right"...

--- peterd



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