Re: [xri] TAG discussion of versioning in URIs

From
Peter C Davis <>
Date
2003-04-22T19:51:46+00:00
ID
Thread
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
>
>  
>
>>-----Original Message-----
>>From: Wachob, Gabe [mailto:]
>>Sent: Tuesday, April 22, 2003 12:25 PM
>>To: ''
>>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
>>
>>    
>>
>>>-----Original Message-----
>>>From: Peter C Davis [mailto:]
>>>Sent: Tuesday, April 22, 2003 7:49 AM
>>>To: ''
>>>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
>>>
>>>      
>>>