[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), Here's some of your use case examples: > 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 I think that the $ dictionary might define "$cond*in" instead of separately defining "$cond" and "$in". I think that would result in the following: =John*personas*($cond*in*(@commons*members)) 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]