abbreviation mechanism for XRI's

I like this a lot and will start using
it in my documents. However... Is it valid for XRI 2.0? if not I'm not
going to include support for it in the actual implementations (for now).

Dave? Drummond?

Andy Dale

ooTao

Phone: 877-213-7935

Fax: 877-213-7935

i-name: =Andy.Dale

http://public.xdi.org/=andy.dale

***************************************************************************

If you don't have your iName yet use this link:

   http://2idi.com/registrar/index.html?referral_code=ootao

***************************************************************************

"Barnhill William"
<> 

06/30/2005 06:32 AM

To

<>

cc

Subject

RE: [xdi] Dollar word proposed for data
types-$type

 

Ah, ok. I thought it was $l-en. If we used
hierarchy for the $l system I agree, we should use it for this as well.
Also, after thinking about it hierarchy does make sense, though it adds
more parens.

 

What are everyone's thoughts on a possible abbreviation
mechanism for XRI's, and on the following ideas for such an mechanism?
IMHO some of the XRIs we're using in our examples are very long, and an
abbreviation scheme would be nice for five reasons:

(1) Increased human readability (low priority)

(2) Decreased bandwidth (high priority)

(3) Streamlined XRI parsing (if you parse an abbreviated
authority once, you can cache it for rest of XRI. Implementers will do
caching anyway, but an abbreviation would make recognizing when to pull
from cache easier)

(4) If we want people to be able to type XRIs or, more
likely, use them as links in a browser, then I seem to remember a 256 character
limit in IE, possibly other browsers.  That limit may have been removed
by now, I'm don't know.

(5) Referencing parts of the XRI in the XRI processing

 

The scheme I'm thinking of would use some grouping characters
not used by XRI spec currently..[], perhaps? These would be used in a manner
similar to the way regex groups work. Where you have a repeated XDI addressing
path xxx, you'd replace the first instance with [somelabel|xxx] and further
instances with [somelabel]. For most cases this would be [1|xxx] and [1].
Another decision would be whether or not to allow nesting. 

 

Bill Barnhill

Senior Consultant (XML, Emerging Technologies,
Web Services, Java)

Booz | Allen | Hamilton

mailto:

phone:+1.315.330.7386

 

From: Drummond Reed [mailto:]

Sent: Wed 6/29/2005 11:59 PM

To: Barnhill William

Subject: RE: [xdi] Dollar word proposed for data types-$type

Cool idea. $type is already one of our "default dollar
words" by virtue of

being one of the XDI schema elements. And at first blush this seems like
a

good use of it. I also like the idea of making the fragment identifiers
in

the W3C Schema Datatypes spec the default.

I also suggest we go with true hierarchy, i.e., slash. This is what we
did

with $l in the XRI Metadata spec - slash delineates the instances of the

type, whereas * delegates to subtypes. For example with $l, the immediate

children (i.e., if there is no delegated *name after $l) are defined to
be

two-letter language tags from (I forget the name of the RFC - see the spec

at

http://www.oasis-open.org/committees/download.php/11854/xri-metadata-V2.0-cd

-01.pdf). For example:

        $l/en           for
English

        $l/fr           for
French

So with the $type space, we would specify (in the Service Dictionary spec)

that the default child namespace under $type is the set of fragment

identifier in the W3C Schema datatypes spec.

        $type/string

        $type/float

Then you could extend type definition to any other namespace as follows:

        $type*(=foo/mytypes)/custom.type

Sure meets the simplicity test. Thoughts?

=Drummond

-----Original Message-----

From:  [mailto:]

Sent: Wednesday, June 29, 2005 7:25 PM

To: 

Subject: [xdi] Dollar word proposed for data types-$type

$type-xxx where xxx is the fragment identifier from the W3C schema datatype

or $type-yyy-xxx where yyy is the ident for a type system other than W3C

schema datatypes.