RE: [xri] A question on syntax shortcuts

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

Hi Marty & all,

In an effort to better explain my thinking on this I'm going to try to
go step by step. This will also make it easier for you to spot any flaws
in my process:
- An XRI addresses a resource
- An XRI addressed resource has a type which determines the type of the
data addressed. This type could be an XML Schema type, a MIME type, or a
$ dictionary definition.  The only requirement on the type is that the
on-the-wire format of the addressed data is determined by the type. In
XDI this type is the 1st path segment, i.e. XDI XRI's have the general
form data authority/data type/data instance identifier, corresponding
roughly to the subj, pred, and object of an RDF triple.
- A condition is a function whose input is an XRI of type XRI collection
(how this is represented is unknown but expected it'd be in $
dictionary), and whose output is addressed by the XRI produced by
appending the condition segments to the XRI addressing the XRI
collection over which the condition will operate (still need to specify
how/if query string, frag id, and conditions for auth, type are handled)

To give an example take $cond*beforeDate*($d*1994-11-05T08:15:30Z).
Let's say I =Bill.Barnhill have published data about my past vacations.
Being interoperable conscious I checked for an already defined +vacation
resource and found it. Within the definition for +vacation is specifies
that each vacation has a destination (xsd:String) and a date (xsd:Date).
Using a convention for getting all instances of a type under an
authority I can address all of my vacations with
=Bill.Barnhill/+vacation which returns an XDI document containing a link
to each vacation resource.

Now consider the XRI
=Bill.Barnhill/+vacation*$cond*beforeDate*($d*1994-11-05T08:15:30Z).
What does it address?
It addresses an XDI document containing a link to each vacation resource
whose date resource passes the condition. It bases this based on looking
for a field of the type the condition expects, xsd:Date within each
checked resource.

What if there are more than one date resource, or if we want to
explicitly state the field within the resource that is being checked?
These seem to be what you are asking and I'm not sure of the answer. My
thought is that it would be specified by a relative XRI xref following
the $cond segment that addressed into the elements of the collection,
for example:
=Bill.Barnhill/+vacation*$cond*(/date)*(beforeDate*($d*1994-11-05T08:15:
30Z)

Hmm, not sure on this so am going to need to think about it more.
What has me wondering is that if I wanted to reference the date within
say the toronto vacation the XRI might be something like:
=Bill.Barnhill/+date/+vacation*toronto

So maybe the vacations after the given date should be represented by:
=Bill.Barnhill/+date/+vacation*$1*$cond*(beforeDate*($d*1994-11-05T08:15
:30Z)*$result*(=Bill.Barnhill/+vacation/$1)
Which increases complexity by using params and a result segment (similar
to select clause within SQL)

Hmm, definitely food for thought, but need to switch back to coding and
abstracts for now, and likely until weekend. Hopefully I can work on
this a bit more over the weekend.

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: Schleiff, Marty [mailto:marty.schleiff@boeing.com] 
Sent: Tuesday, December 12, 2006 1:00 PM
To: Barnhill, William; Sakimura, Nat; xri@lists.oasis-open.org;
xdii@lists.oasis-open.org
Subject: RE: [xri] A question on syntax shortcuts

Hi Bill (& All),

I'm still scatching my head trying to understand how a resource is
checked against a specified condition. You said, "The compared data is
just that..the data represented by the XRI, not the XRI itself.". Then
the data represented by the XRI would have to have some understood
structure so it can be determined if the data meets the condition. If
you're trying to identify a set of resources with
"$cond*beforeDate*($d*1994-11-05T08:15:30Z)", then should the comparison
be done against some defined metadata tag in the resource, or the
appearance of a date somewhere in the text of a document resource, or
what?  Also, if some resources are not digital in nature (i.e., they
don't consist of data), then how can they be compared to the conditions?
Would it make sense to do comparisons against some structured
information in a resource's XRD?

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: Thursday, December 07, 2006 4:36 PM
> To: Barnhill, William; Sakimura, Nat; Schleiff, Marty; 
> xri@lists.oasis-open.org; xdii@lists.oasis-open.org
> Subject: RE: [xri] A question on syntax shortcuts
> 
> Revised hierarchy to include date $-words:
>  
> 
> $function.xricollection
>     $restriction
>          $cond
> 		 $date.cond
>                   $afterDate
>                   $beforeDate
>                   $onDate
>                   $betweenDates
>              $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
> 
> Note that XPL conditions are each a function mapping a collection of 
> data instances referencable by XRIs to a collection of data instances 
> referencable by XRIs. The compared data is just that..the data 
> represented by the XRI, not the XRI itself. I believe we have a method

> within XDI to have XRI addressability of the XRI value within a 
> <link>, so we CAN compare XRIs with the condition operators.
> 
> Regards,
> 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: Barnhill, William [mailto:barnhill_william@bah.com]
> Sent: Monday, December 04, 2006 9:41 AM
> To: Sakimura, Nat; Schleiff, Marty; xri@lists.oasis-open.org
> Subject: RE: [xri] A question on syntax shortcuts
> 
>  
> Ah, realized something else. I should NOT have said
> =John*personas*($cond/$in/(@commons*members)) 'resolves to', instead I

> should have said 'when input to an XRI Path Engine results in', as my 
> proposal was not to change the XRI resolution process.
> 
> OTH (On the gripping hand for the Sci-fi fans), IMHO it would be very 
> useful to allow optional support of XPL at the resolver level, perhaps

> with a 501 Not Implemented response with a message of "XPL vx.y not 
> supported.". I thought about a redirect to the XRI without conditions,

> but then you are returning results that might be misconstrued as 
> meeting the conditions.
> 
> This could also be part of a bigger thing: Is there any mechanism to 
> describe optional capabilities on an XRI resolver over and above the 
> core requirements? For HTTP, something like an X-xri-requires: header 
> on requests and
> X-xri-supports: header on responses.  
> 
> Thanks,
> Bill
> 
> -----Original Message-----
> From: Barnhill, William [mailto:barnhill_william@bah.com]
> Sent: Monday, December 04, 2006 9:17 AM
> To: Sakimura, Nat; Schleiff, Marty; xri@lists.oasis-open.org
> Subject: RE: [xri] A question on syntax shortcuts
> 
> 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.f
> or/(@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
> 
>  
>