RE: [xri] [Issue 12] Explaining "profile" concept

["Wachob, Gabe" <gwachob@visa.com>]

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