OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xdi message

[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]