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

Title: 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.