[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xri] [Issue 6] Versions and profiles
+1 for me. I think there are valid cases for XRI's which need not resolve "today" to the resource identified "prior-to-today", or in a different state... --- peterd Drummond Reed wrote: >Just to go on record, I'm not on board that versioning syntax should not >be available at all levels. There is one perspective - an all XDI-based >resolution mechanism - where versioning of top-level authorities for >either XRI-URIs or XRI-URNs would be a valuable use case. > >I understand that versioning may not be advantageous at the top level >when using other resolution mechanisms, but I don't think this should >automatically disqualify it from any consideration. I think it would be >cleaner to make it an optional feature at the top level for certain >resolution mechanisms. > >=Drummond > >-----Original Message----- >From: Dave McAlpin [mailto:dave.mcalpin@epokinc.com] >Sent: Friday, April 25, 2003 11:18 AM >To: 'Wachob, Gabe'; xri@lists.oasis-open.org >Subject: RE: [xri] [Issue 6] Versions and profiles > >I changed the issue in the title to 6 to reflect that fact that we're >focusing on versioning here. > >I'm on board with the fact that versioning should be excluded from the >authority component to simplify resolution, I just want it to be a >"required >to understand, optional to do anything about" aspect of the local part. >Basically my argument is that it's cheap to understand basic versioning >syntax and splitting it out into an optional profile impacts >interoperability unnecessarily. > >Consider a similar example with HTTP URLs. Let's say >http://www.xriexample.org/foo doesn't expect a query string, but someone >accesses it as http://www.xriexample.org/foo?bar=fred. What should the >server do? I'd say it should either ignore the query string and just >return >foo or it should return some sensible error related to the incorrect >query >(maybe 400 Bad Request?). What I _don't_ think it should do is >understand it >as a request for a resource named foo?bar=fred and return a 404. In >other >words, even though the server has no interest in the query string and no >logic to process it if it's included, it should still understand the >syntax >well enough to know that a query string's included. > >I think the same should apply to versioning. I'm not saying everyone has >to >do something sensible with a version request, I'm just saying everyone >should understand that a version is being requested. > >Dave > >-----Original Message----- >From: Wachob, Gabe [mailto:gwachob@visa.com] >Sent: Thursday, April 24, 2003 9:43 AM >To: 'Dave McAlpin'; xri@lists.oasis-open.org >Subject: RE: [xri] [Issue 12] Explaining "profile" concept > >Yes, you are closer in line to what I'm thinking of. > >We need a better term than "profile" it appears. But at least the >concept is >clear and we can discuss the concept w/r/t versioning over in the >versioning >thread. > > -Gabe > > > >>-----Original Message----- >>From: Dave McAlpin [mailto:dave.mcalpin@epokinc.com] >>Sent: Thursday, April 24, 2003 8:37 AM >>To: Wachob, Gabe; xri@lists.oasis-open.org >>Subject: RE: [xri] [Issue 12] Explaining "profile" concept >> >> >>Thanks Gabe. Maybe what we're talking about could be called >>"feature sets" >>or simply "features", where an XRI processor would be >>required to implement >>the core functions and could additionally support whatever >>optional feature >>sets it chose. >> >>There are precedents here. ODBC, for example, defines many >>features but only >>requires drives to implement a subset. It also specifies API >>and SQL grammar >>conformance levels that group features into broad categories. A driver >>writer can then say, for example, that a driver fully >>supports SQL grammar >>at the Minimum, Core or Extended level. There are APIs that >>allow a client >>application to perform a query at runtime, discover >>capabilities and adjust >>its behavior based on the support provided by the underlying >>driver. The >>idea is that the application developer isn't writing code >>specific to a >>particular database or driver but rather to the more abstract >>notion of >>"features" that might be (or might someday be) supported by multiple >>drivers. >> >>Is that closer to what you had in mind? Is version of good >>test case for its >>utility in XRIs? If so, I'm going to argue that it's not >>appropriate, at >>least with the current strawman, but I want to make sure I'm >>on the right >>track before I do. >> >>Dave >> >> >> >>>-----Original Message----- >>>From: Wachob, Gabe [mailto:gwachob@visa.com] >>>Sent: Wednesday, April 23, 2003 6:04 PM >>>To: 'Dave McAlpin'; Wachob, Gabe; xri@lists.oasis-open.org >>>Subject: RE: [xri] [Issue 12] Explaining "profile" concept >>> >>> >>>Dave- >>> I'm not sure you get the breadth of what I'm talking about. >>>Let me respond inline. >>> >>> >>> >>>>-----Original Message----- >>>>From: Dave McAlpin [mailto:dave.mcalpin@epokinc.com] >>>>Sent: Wednesday, April 23, 2003 5:51 PM >>>>To: 'Wachob, Gabe'; xri@lists.oasis-open.org >>>>Subject: RE: [xri] [Issue 12] Explaining "profile" concept >>>> >>>> >>>>I think I understand the profile concept in principal and I >>>>think it's a >>>>fine idea. It's easy to imagine a profile around something like >>>> >>>>xri://@Visa/TelephoneExtension/12345 >>>> >>>>where TelephoneExtension defines a profile that says >>>>something like "all >>>>entries in my namespace must be exactly five characters long >>>>and may contain >>>>only the characters 0, 1, 2, 3, 4, 5, 6, 7, 8 and 9". >>>> >>>> >>>I actually don't see "profiles" as typically being defined to >>>apply only to a single namespace. Thats certainly something you >>>could do, but the concept I'm talking about is more foundational. >>>The idea is that there are few of these "profiles" and all >>>implementers are aware of them - some just choose to ignore them. >>> >>> >>> >>>>Is that more or less the idea? If it is, I'm having a hard >>>>time applying it >>>>to the proposals in the strawman. >>>> >>>> >>>I think its not really the idea. More below. >>> >>> >>> >>>>You used version as your >>>>example below and >>>>noted that making it part of a profile rather than the core >>>>syntax makes it >>>>easier for version-ignorant implementations to deal with. But >>>>it seems to me >>>>the opposite is true. If you have >>>> >>>>xri://xrifoo.org/charter[;2001-03-04T20:15:40Z] >>>> >>>>and the [] syntax is core, every processor - whether it >>>>chooses to deal with >>>>version or not - at least understands that the resource is >>>>named charter and >>>>that it's followed by some version information. If the >>>>processor chooses not >>>>to deal with version, it can either return a reasonable error >>>>or ignore the >>>>version altogether, but at least it knows what it's being >>>>asked for and what >>>>to potentially ignore. >>>> >>>> >>>I don't think that its reasonable for it to "understand" that >>>information unless it knows what to do with it. If an application >>>doesn't understand how different versions relate to each other, >>>what can it do with a versioned number of a resource? I don't see >>>any reason to require understanding the syntax if you aren't >>>going to require everyone to understand the semantics -- and in >>>the case of versioning, thats potentially a lot to understand. >>> >>>Certain applications may impose a lot of semantics that are well >>>defined on version strings, and thats great. But a lot of >>>infrastructure won't. >>> >>> >>> >>>>On the other hand, if [] is defined by a profile and the >>>> >>>> >>controlling >> >> >>>>namespace (which is what? xrifoo? charter?) isn't aware of >>>>that particular >>>>profile it'll see the resource name as >>>>charter[;2001-03-04T20:15:40Z] and >>>>just reject it as not found. >>>> >>>> >>>Well, "not found" is a response that a local resolver may give, >>>but not an XRI namespace authority resolver, because the >>>versioning is in the local part of the name. >>> >>>This is why I suggested that versioning in the namespace >>>authority part would present issues. >>> >>>No matter whether versioning is considered "optional" or not, if >>>versioning cannot happen in the naming authority part, then >>>resolution isn't affected. This is why I don't understand your >>>objection - what application would care about the syntax if it >>>didn't care about the semantics (ie multiple instances of >>>resources related along a time-axis)? >>> >>> -Gabe >>> >>> >>> >>> >>>>Am I off base here? >>>> >>>>Dave >>>> >>>>-----Original Message----- >>>>From: Wachob, Gabe [mailto:gwachob@visa.com] >>>>Sent: Wednesday, April 23, 2003 2:18 PM >>>>To: 'xri@lists.oasis-open.org' >>>>Subject: [xri] [Issue 12] Explaining "profile" concept >>>> >>>>Its become clear that this concept (that Mike has referred to >>>>already at >>>>[1]) is causing some confusion. >>>> >>>>The intent for the concept of "profile" (and this is a bad >>>>name, we need to >>>>think of another) is that some features expressed in >>>>syntactical structures >>>>are interesting to some applications or users but not all >>>> >>>> >>users and >> >> >>>>applications. Furthermore, for some of these features, they >>>>can be safely >>>>ignored by the common infrastructure supporting the wide >>>>interoperability of >>>>identifiers (which is primarily the resolution infrastructure). >>>> >>>>Thus, it would be a big win if some features could be >>>>declared in a way that >>>>infrastructure (resolvers, parsers, etc) could safely ignore >>>>the syntactic >>>>structures corresponding to the feature in question. Such >>>>features would >>>>then exist as a "profile" (which is a bad term). This means, >>>>in part, that >>>>*implementation* of code which treats these syntactic >>>>structures specially >>>>would be *optional*. System components would still function >>>>(albeit with >>>>dimished semantic functionality) even if they didn't >>>>understand all the >>>>structure and semantics of identifiers using the >>>> >>>> >>"profiled" features. >> >> >>>>An example would be helpful. Lets say we could declare >>>>"versioning" as a >>>>"profiled" (optional?) feature. This means that the stuff in >>>>between [] >>>>(using our current versioning proposal) would have no special >>>>meaning to >>>>components that didn't care about versioning. In this case, >>>>the versioning >>>>part of the identifier would simply be more characters. >>>> >>>>Take the example XRI xri://xrifoo.org/charter[:1.2] >>>> >>>>To a component that understood versioining, it would >>>> >>>> >>parse this into >> >> >>>>(xrifoo.org, charter, [:1.2]) components. That component >>>>would understand >>>>that we are referring to a version of a resource and may want >>>>to attempt >>>>behavior that only makes sense with a versioned resource >>>>(like retrieving >>>>previous versions) >>>> >>>>A version-ignorant component, on the other hand, would >>>> >>>> >>parse this into >> >> >>>>(xrifoo.org, charter[:1.2]) and would not understand any >>>>relationship to >>>>other resources which may be different "versions" of the same >>>>thing. This >>>>sort of behavior is entirely reasonable for resolvers, for >>>>example, who are >>>>unconcerned with anything but the naming authority part >>>> >>>> >>(xrifoo.org). >> >> >>>>Other candidates for "profiling" (again, yechy term) are >>>> >>>> >>any sort of >> >> >>>>specification which structures the stuff to the right of the >>>>3rd '/' (ie the >>>>"local part" of the XRI). By definition, this stuff doesn't affect >>>>resolution. You could have profiles wihch *restrict* or >>>> >>>> >>*give special >> >> >>>>meaning* to otherwise legal naming authority identifiers, etc. >>>> >>>>To be clear, by saying "non-core" Mike doesn't neccesarily >>>>mean "not in the >>>>adressing and resolution spec", but rather he means "defined >>>>as a 'profile' >>>>- something which needs only to be optionally implemented in >>>>components". >>>> >>>> -Gabe >>>> >>>> >>>>[1] http://lists.oasis-open.org/archives/xri/200304/msg00036.html >>>> >>>> >>>> >>>>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]