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