RE: [xri] A question on syntax shortcuts

["Barnhill, William" <barnhill_william@bah.com>]

Hi Nat, Marty, and all,

If I understand correctly you are both talking about using condition
restrictions on data that's textual (Btw, do we have accepted dollar
words for primitive types? Last I heard we were going to re-use the XSD
definitions, but not sure.). I only meant for $lt, $gt, $eq, $ge, $le to
be used on data that is numeric, and eventually I hope there is a
mechanism for defining ordering within an XDI dictionary, so a
particular dictionary can give order to complex types similar to what
Java does with Comparator.

For $xsd:string I was going to use four conditions:
-- $like, which has same syntax as SQL 'Like', and its inverse $notlike
-- $match, which has same syntax as PERL RegEx, and it's inverse
$nomatch

Using the above conditions for textual data avoids the ordering thorn,
at the expense of not having alphabetization capability, which I can
live with as that's something that can be done externally. 

The other thing is that I see these conditions as more like operators
that act on like a filter  function on the results of an XRI that
returns a collection of zero or more things, filtering the returned
collection to only items that pass the condition. That could be
expressed by having them be instances of $restriction, an abstract $cond
type.

I hope the ability will exist in the final dictionary to allow users to
add conditions under their authority.  So for example a condition to
order the collection would be an instance of an $ordering, another
abstract $cond type. This means @example could define
@example*$cond/$alphabetize to order the results of an XRI that returns
a collection of 'things that are textually represent able'.

Pulling together my thoughts somewhat to produce the hierarchy I am
seeing:

$function.xricollection
    $restriction
         $cond
             $textual.cond
                  $match
                  $like
             $numeric.cond
                  $lt
                  $le
                  $gt
                  $ge
                  $eq
                  $neq
             $set.cond
                  $in
                  $not.in
                  $contract.with
                  $contract.for
    $trans (short for transform
         $ordering.trans
             $textual.ordering
                  $alphabetize
                     $alphabetize*$lang*en
                     $alphabetize*$lang*jp
                  $inv.alphabetize
             $numeric.ordering
                  $ascending
                  $descending
         $set.trans
             $union
             $difference
             $intersection
             $complement

One reason I like the addition of the set ops is the following use case:

UC 1
1. XRI =John*personas resolves to an XDI document with =John as
authority,a type +persona, and instances =A, =B, =C, =D

2. XRI @commons*members resolves to an XDI document with @commons as
authority, type +persona, and instances =L..=Z,=B,=C

3a. Then the XRI =John*personas*($cond/$in/(@commons*members))
or 3b =John*personas*($cond*$in*(@commons*members))
or 3c =John*personas*$3*$cond*$in*$2*@commons*members

resolves to an XDI document with =John as authority, type +persona, and
instances =B,=C which has the meaning of "=John's personas that are
members of the community @commons"

As an aside, if the two original XRIs were modelled as =John/+persona
and @commons/+member then the above becomes alt 3a. Then the XRI
=John/+persona/($cond/$in/@commons:members)
or alt 3b =John/+persona/($cond*$in*@commons:members)
or alt 3c =John:+persona*$3*$cond*$in*$2*@commons:members

Looking at it I'll concede the alternate versions with colons don't seem
cleaner, though to me alt 3a is the clearest in meaning to a human
reader.

For a more complex example, a single XRI that expresses "=John's
personas that are members of the @commons community and have access to
@example's budget for 2006."
=John/+persona/($cond/$in/@commons:members)*($cond/$contract.for/(@examp
le/+budget/2006))

Have to context switch back to XDI Service doc, more on the above later
after I digest feedback.

Thanks,
Bill 

-- 
William Barnhill                    Phone: (315) 491-6765
Associate                           Email: barnhill_william@bah.com
Booz | Allen | Hamilton             i-name: =Bill.Barnhill
"Delivering results that endure" 

-----Original Message-----
From: Sakimura, Nat [mailto:n-sakimura@nri.co.jp] 
Sent: Saturday, December 02, 2006 9:02 PM
To: Schleiff, Marty; Barnhill, William; xri@lists.oasis-open.org
Subject: RE: [xri] A question on syntax shortcuts

Hi Marty, 

Just a short comment on the search. 

> $ 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?

Yes, it does. For instance, for Japanese, you just cannot reduce the
characters to ascii space. Also, we have a definite ORDER in the
characters. 

Regards, 

Nat