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