[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] A question on syntax shortcuts
Hi Marty (& all), Having the $ dictional define $cond*in instead of $cond and $in does work, but what does 'in' represent? If it only represents the concept of the condition of resource membership within a set then $cond*in has no problems. If OTH it represents the concept of membership within a set, a somewhat more general and reusable concept, then you'd want a $in as well, which would then mean you have $cond*in and $in. That's doable but seems more confusing than $cond*$in or $cond/$in in that case. I'm thinking of $cond*$in means "$in in the context of $cond", whereas $cond*in means the $cond 'in'. This distinction between the meanings may not be necessary, might just work to pick one and mark it for revisit once we have user feedback. I'm not strongly tied to either one. 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: Schleiff, Marty [mailto:marty.schleiff@boeing.com] Sent: Tuesday, December 12, 2006 12:47 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), 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]