[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] A question on syntax shortcuts
Fair enough. Based on that I'd agree on $cond*in format. -- 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 3:13 PM To: Barnhill, William; Sakimura, Nat; xri@lists.oasis-open.org; xdi@lists.oasis-open.org Subject: RE: [xri] A question on syntax shortcuts Hi Bill (& All), I wish I could experience a big "AHAH!" and then understand everything. Sadly, all I get is a little "ah" every once in a while, so it takes me a while to understand. Today's "ah" is that you are talking about XDI stuff (eXtensible DATA Interchange), so the resources you're talking about tend to be DATA resources. I understand a little better than before that the data resource's MIME type, or schema type, could provide the key to understanding how to check for condition matches. In the $ dictionary, should we define "$in" to represent an abbreviation for Indiana, or the notion of "in" a set, or a possible shape of belly-button, or something else? For the French language, we don't have "$fr"; rather, we have "$l*fr". That's why I'm leaning toward something like "$cond*in" to represent "in" a set. 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: Tuesday, December 12, 2006 11:42 AM > To: Schleiff, Marty; Sakimura, Nat; xri@lists.oasis-open.org; > xdi@lists.oasis-open.org > Subject: RE: [xri] A question on syntax shortcuts > > > Hi Marty & all, > > In an effort to better explain my thinking on this I'm going to try to > go step by step. This will also make it easier for you to spot any > flaws in my process: > - An XRI addresses a resource > - An XRI addressed resource has a type which determines the type of > the data addressed. This type could be an XML Schema type, a MIME > type, or a $ dictionary definition. The only requirement on the type > is that the on-the-wire format of the addressed data is determined by > the type. In XDI this type is the 1st path segment, i.e. XDI XRI's > have the general form data authority/data type/data instance > identifier, corresponding roughly to the subj, pred, and object of an > RDF triple. > - A condition is a function whose input is an XRI of type XRI > collection (how this is represented is unknown but expected it'd be in > $ dictionary), and whose output is addressed by the XRI produced by > appending the condition segments to the XRI addressing the XRI > collection over which the condition will operate (still need to > specify how/if query string, frag id, and conditions for auth, type > are handled) > > To give an example take $cond*beforeDate*($d*1994-11-05T08:15:30Z). > Let's say I =Bill.Barnhill have published data about my past > vacations. > Being interoperable conscious I checked for an already defined > +vacation resource and found it. Within the definition for +vacation > is specifies that each vacation has a destination (xsd:String) and a > date (xsd:Date). > Using a convention for getting all instances of a type under an > authority I can address all of my vacations with > =Bill.Barnhill/+vacation which returns an XDI document containing a > link to each vacation resource. > > Now consider the XRI > =Bill.Barnhill/+vacation*$cond*beforeDate*($d*1994-11-05T08:15:30Z). > What does it address? > It addresses an XDI document containing a link to each vacation > resource whose date resource passes the condition. > It bases this based on looking for a field of the type the condition > expects, xsd:Date within each checked resource. > > What if there are more than one date resource, or if we want to > explicitly state the field within the resource that is being checked? > These seem to be what you are asking and I'm not sure of the answer. > My thought is that it would be specified by a relative XRI xref > following the $cond segment that addressed into the elements of the > collection, for example: > =Bill.Barnhill/+vacation*$cond*(/date)*(beforeDate*($d*1994-11 -05T08:15: > 30Z) > > Hmm, not sure on this so am going to need to think about it more. > What has me wondering is that if I wanted to reference the date within > say the toronto vacation the XRI might be something like: > =Bill.Barnhill/+date/+vacation*toronto > > So maybe the vacations after the given date should be represented by: > =Bill.Barnhill/+date/+vacation*$1*$cond*(beforeDate*($d*1994-1 1-05T08:15 > :30Z)*$result*(=Bill.Barnhill/+vacation/$1) > Which increases complexity by using params and a result segment > (similar to select clause within SQL) > > Hmm, definitely food for thought, but need to switch back to coding > and abstracts for now, and likely until weekend. > Hopefully I can work on this a bit more over the weekend. > > 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: Schleiff, Marty [mailto:marty.schleiff@boeing.com] > Sent: Tuesday, December 12, 2006 1:00 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), > > 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]