OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]