RE: [xdi] abbreviation mechanism for XRI's

Bill,

 

The labelled cross-reference bit might
better be handled by a $ letter added to the XRI Metadata spec, since this
doesn't require extending XRI syntax. Perhaps "$." or something like
that. So your cross-reference would be…

 

            ($./mylabel*(XRI-Authority))

 

Just an idea (and still I think only
useful if there are a lot of repeated authority or type XRIs, but I may not yet
fully understand this proposal).

 

As for your question about xri:(foo*bar)*baz/
equivalent to xri:foo*bar*baz/? Is xri:foo*(bar*baz)/ equivalent to
xri:foo*bar*baz/ ? The answer is both cases is no. The easy way to think of it
is that from the standpoint of resolution, cross-references are literals. Insert
one and the value being resolved changes.

 

For example, even xri://foo and xri://(foo) are not equivalent. They
MAY resolve to the same resource and thus be proved to be equivalent otherwise,
but not by XRI equivalence rules alone.

 

=Drummond 

 

 

From: Barnhill William
[mailto:] 

Sent: Thursday, June 30, 2005 12:21 PM

To: 

Subject: RE: [xdi] abbreviation
mechanism for XRI's

 

Thanks Dave. I see how we can use xrefs
to reference a segment group within the XRI, though that also might be prone to
cycles.  I don't immediately see how to use xrefs to delineate a segment
group within an XRI and preserve the semantic meaning of the XRI.  You,
Drummond, et al. know XRIs way better than I do, any ideas? 

 

Also, is there a XRI 2.1 or 2.0a rev planned, and is there
any possibility of the ref production going from

       xref = "("
(XRI-reference / IRI) ")"

to

       xref = "("
(XRI-reference / IRI / "(" (label
[":" XRI-Authority ) ")" ) ")"

or perhaps the more easier to read version

       xref = "("
(XRI-reference / IRI / lref ) ")"

       lref =
"(" (label [":" XRI-Authority ) ")" 

 

I would need a yacc run to make sure this parses without ambiguity. If
anyone has a yacc or similar xri grammar and wants to try the change I'd
appreciate it, as I won't be able to set that up until later this
weekend. 

 

Which brings up another XRI question:

is xri:(foo*bar)*baz/ equivalent to xri:foo*bar*baz/ ?

How about xri:foo*(bar*baz)/ equivalent to xri:foo*bar*baz/ ?

This kind of brings to mind the previous discussion on an algebra for
XRI/XDI, but that's for another day.

 

Bill

From: Dave
McAlpin [mailto:]

Sent: Thu 6/30/2005 1:50 PM

To: Barnhill William;


Subject: RE: [xdi] abbreviation
mechanism for XRI's

I agree with your analysis, i.e. square
brackets and braces aren’t available and can’t be used. The only
legal characters are in the xri-sub-delims production, and none of those are
“balanced”, like parens or brackets. I think your only option is to
use some form of cross-reference.

 

Dave

 

From: Barnhill William
[mailto:] 

Sent: Thursday, June 30, 2005 10:43 AM

To: 

Subject: FW: [xdi] abbreviation
mechanism for XRI's

 

I did a little digging into the XRI 2.0
and IRI specs.

 

"[" and "]" Are
xri-gen-delims, which does mean they are currently reserved, so this would
require an XRI spec mod.

However, XRI makes no use of these chars, they're marked as
xri-gen-delims as they are reserved in IRI.

 

Their use within IRI is for IP literals (ie. for IPv6+).
With that in mind "[" are prob out. Perhaps "{"
"}", which are not covered under XRI or IRI. Of course then we have
the problem of readability between "{}" and "()". Brackets
would be ideal, but then XDI addresses would not be XRIs, or XRIs
would not be IRIs, neither of which are acceptable I'd think.

 

Another option, though somewhat ugly is
((label:oneormoresegments)) which also makes the grouping looking like a
special kind of cross-reference, which in a very loose sense it would seem to
be. The following would reference the labelled segments ((label)). This may be
the most workable as ")" is a xri-sub-delim, and it may be in line
with our current use of "(", though I'm leary of making
"("'s meaning depend on the character that follows it.

 

 

Bill Barnhill

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

Booz | Allen | Hamilton

mailto:

phone:+1.315.330.7386

 

From:
 [mailto:]

Sent: Thu 6/30/2005 12:00 PM

To: 

Subject: [xdi] 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.

--

Checked by AVG Anti-Virus.

Version: 7.0.323 / Virus Database: 267.8.7/34 - Release Date: 6/29/2005