[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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.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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]