[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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 > > > >>-----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]