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

Is that more or less the idea? If it is, I'm having a hard time applying it
to the proposals in the strawman. 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.

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.

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]