RE: [xri] A question on syntax shortcuts

["Drummond Reed" <drummond.reed@cordance.net>]

Bill, Marty:

I was offline all day yesterday at a conference and am preparing now to
leave tomorrow for Internet Identity Workshop all next week (it goes
Mon-Wed, but Thursday Gabe is hosting a XRI $ Dictionary meeting and Friday
I have an XDI meeting with Andy Dale).

I just saw both your messages and they raise a host of fascinating
possibilities and questions. I don't know about anyone else but I personally
need not just a few minutes but a few hours to think these through before
responding.

And I'd really like for us to have a chance to all discuss this together
sometime on either the XDI TC call from 3-4PM PT this coming Thursday, or
the XRI TC call that follows immediately after (on the same bridge) from
4-6PM PT.

I any case, I'll send something as soon as I can, and I encourage others to
continue discussion on the list/wiki.

=Drummond 

-----Original Message-----
From: Schleiff, Marty [mailto:marty.schleiff@boeing.com] 
Sent: Saturday, December 02, 2006 8:05 AM
To: Barnhill, William; xri@lists.oasis-open.org
Subject: RE: [xri] A question on syntax shortcuts

Hi Bill (& All),

Your $ namespace examples show concepts that Drummond and I express a
little differently, or that we haven't yet figured out how to express at
all. Heres some of our current thoughts that might impact what you are
doing. Also, you inspired a couple new thoughts in me, that I haven't
run past Drummond yet.

First of all, Drummond coined the following words for the Metadata spec:
'For simplicity, the XRI subsegment delimiter used with XRI metadata is
defined as a "*".' You may want to replace some of the slashes with
asterisks and see if that helps or makes matters even worse.

We have also mentioned (but not deeply explored) the notion of
conditions like gt, lt, eq, ge, and le. Following the form of other the
$ dictionary, if we define "$cond", then the way to express 'less than'
would look like '$cond*lt'. The $cond says that the lt is a condition,
so you could drop the plus signs in front of lt.

The notion of conditions raises another question: do non-ascii
characters have a different notion of ordering? Or do we just order
their ascii representations? Or what?

In the @ namespace, some values are reserved for special purposes (I
think any single character, and TLDs like com and net). In the $
namespace we could consider reserving some values for special purposes.
Or, another way to look at it is that the whole $ dictionary is a list
of reserved words and their definitions. My thought is that we could
reserve numbers for special purposes, two of which come to mind:

A) "$1" and "$27" might be used as variables instead of "$$iname" or
"$var/iname".

B) In Thursday's call Gabe mentioned an idea of a length indicator for
how many subsegments belong to an XREF (in case we want to represent
multi-subsegment XREFs without parentheses. So maybe instead of
"($cond/+gt/$date:2006-11-01)" you could try something like
"$3*$cond*gt*$2*$date*2006-11-01" which would cannonicalize to
"($cond*gt*($date*2006-11-01))". Although such an idea might allow
reduced use of parentheses, I think I actually prefer the example WITH
the parentheses.

Of course only one of special purpose A or B could be supported. I favor
B, maybe because I don't fully understand the use case for variables. It
seems to me like you're trying to build matching logic into the XRI,
whereas I'm much more comfortable with matching logic that is provided
by the software doing the matching. Oracle/databases provide the "where"
clause for matching, complete with conditions, wild cards, boolean
logic, etc. LDAP provides the search "filter" complete with conditions,
wild cards (different than the Oracle wild card), and boolean logic.
Grep, awk, perl, and many others support regular expression matching.
The work we're doing to define connonical representations is also
intended primarily to support simple string matching and ordering.

Marty.Schleiff@boeing.com; CISSP
Associate Technical Fellow - Cyber Identity Specialist
Computing Security Infrastructure
(206) 679-5933
 

> -----Original Message-----
> From: Barnhill, William [mailto:barnhill_william@bah.com] 
> Sent: Friday, December 01, 2006 11:44 AM
> To: xri@lists.oasis-open.org
> Subject: [xri] A question on syntax shortcuts
> 
> 
> With some of the stuff I am working on I am running into an 
> abundance of parens. The paren shortcut allowing stuff like
> =bill.barnhill+tag1 was a big help. I still am collecting 
> parens a bit though as many of the cross-refs I'm using are 
> of the form a*(b/c), which I can't shorten to a*b/c.
> 
> An example of this is the following XRI for XDI path language 
> (XPL, something I'm working for submission to XRI/XDI but 
> it's not cooked enough for submission yet) that represents 
> the statement "Give me all articles tagged with the itag I 
> input by the author with the iname I input that were 
> published in the month of Nov 2006:
> ($var/+iname/1)/+article/+($var/+itag/2)+($cond/+gt/($date/200
> 6-11-01))+
> ($cond/+lt/($date/2006-12-01))
> 
> What I'd like is to be able to express that as one of the 
> following (order is from more preferred to less)
> A)
> $$1:+iname/+article/+$$2:+itag+($cond/+gt/$date:2006-11-01)+($
> cond/+lt/$
> date:2006-12-01)
> B)
> $$iname/+article/+$$itag+($cond/+gt/$date:2006-11-01)+($cond/+
> lt/$date:2
> 006-12-01)
> 
> Option B would need the following additional rules:
> .. Any dollar word beginning with two $ is a variable, with 
> the rest of the dollar word after the $$ being the variable 
> name. Example: ($var/1) = $$1, Example: ($var/iname) => 
> $$iname .. An cross-reference consisting of an absolute XRI 
> with only a single segment non-xref authority and a single 
> segment path can be abbreviated without parens by replacing 
> the path delimiter with a colon, this is then called an 
> abbreviated cross-reference. The portion of an abbreviated 
> cross-reference before the colon is the qualifier, and the 
> portion after the value of the abbreviated cross-reference. I 
> think that this means an abbreviated cross-reference wouldn't 
> be mistaken for a IRI as the IRI scheme couldn't be started 
> with a GCS.  Example:
> ($date/2006-12-01) => $date:2006-12-01
> .. Within parsers the ':' operator is given higher precedence 
> than the '/', '*', '!', '(', ')' operators, so a:b*c, a:b!c, 
> a:b/c, a:b(c) will be treated respectively as (a/b)*c, 
> (a/b)!c, (a/b)/c, (a/b)(c)
> 
> Option A would need the same rules as option B, and the 
> following rules:
> .. Any abbreviated cross-reference in which the qualifier is 
> a variable has a value that represents the type of the data 
> represented by the value of the variable.  Example: 
> $$1:+iname .. Specifying the type of a variable through an 
> abbreviated cross-reference is optional. Example: The 
> variable '1' might be expressed within an XPL expression as 
> $$1 and represent any type of data, or as $$1:+iname and be 
> expected to hold an iname (community or global).
> 
> ** Is the $$ syntax cleaner than the longer 
> ($var/type/instance) syntax?
> 
> ** Is there a standard for this already (either a dollar word 
> like $var or a shortcut like $$)?
> 
> ** What are the issues in the above proposed rules and what 
> do you think?
> 
> Thanks,
> Bill
>