[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xri] A question on syntax shortcuts
Hi Bill,
Because you are able to express "and" of conditions, I don't think you need $betweenDates.
--------------------------
Sent from my BlackBerry Wireless Handheld
-----Original Message-----
From: Barnhill, William
To: Barnhill, William; Sakimura, Nat; Schleiff, Marty; xri@lists.oasis-open.org; xdii@lists.oasis-open.org
Sent: Thu Dec 07 16:36:09 2006
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]