OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [xri] [Issue 6] Versions and profiles

Just to be clear, I'm not suggesting that versioning syntax on the
resolvable portion isn't useful, just that I'm willing to defer it to a
later stage if it substantially simplifies the first rev of the resolution

-----Original Message-----
From: Peter C Davis [mailto:peter.davis@neustar.biz] 
Sent: Monday, April 28, 2003 9:25 AM
To: Drummond Reed
Cc: Dave McAlpin; Wachob, Gabe; xri@lists.oasis-open.org
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.
>-----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
>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
>foo or it should return some sensible error related to the incorrect
>(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
>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
>well enough to know that a query string's included.
>I think the same should apply to versioning. I'm not saying everyone has
>do something sensible with a version request, I'm just saying everyone
>should understand that a version is being requested.
>-----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
>        -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
>>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.
>>>-----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
>>>    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
>>>>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
>>>>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
>>>>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?
>>>>-----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
>>>>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
>>>>  -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]