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


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: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
> 
> > -----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:
> > 
> > >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]