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