RE: [xri] FW: Service selection

["Tan, William" <William.Tan@neustar.biz>]

No, I don't intend to change the meaning of match="null" which is to match an element if the criterion is a null string or is absent entirely.

Without match="default", we do lose the "match ONLY if nothing else matches" property. So, you're right, if there was another service with an explicit path match, forwarding service would still be selected. The hack would be to make the Service a low priority. This is a sacrifice in favor of a simpler service selection process. I'm just tossing an idea to see what the reactions are.

I would still like to get some feedback on the other two proposals (which I believe are much less problematic and are backward compatible):
1. Do NOT add match="default" elements (8.2.1). If it's optional it can be made explicit reducing one step from the spec.
2. Remove match="none". AFAIK this was meant to turn off a service completely, like an "#if 0" block.

=wil (http://xri.net/=wil)
 
 

> -----Original Message-----
> From: Steven Churchill [mailto:steven.churchill@xdi.org]
> Sent: Tuesday, August 15, 2006 2:33 PM
> To: Tan, William; xri@lists.oasis-open.org
> Subject: RE: [xri] FW: Service selection
> 
> 
> Wil,
> 
> One of the properties of match="default" was to say "match this ONLY if
> nothing else matches". Do you intend match="null" to have the same meaning?
> For example, I am concerned that if there was another service with an
> explicit (match="content") path match, then the forwarding service would
> be
> always selected as well.
> 
> ~ Steve
> 
> 
> > -----Original Message-----
> > From: Tan, William [mailto:William.Tan@neustar.biz]
> > Sent: Monday, August 14, 2006 9:17 PM
> > To: Steven Churchill; xri@lists.oasis-open.org
> > Subject: RE: [xri] FW: Service selection
> >
> > In the absence of match="default", I think the following does satisfy
> > those two requirements.
> >
> > <Service priority="9999">
> >   <Type select="true">xri://+i-service*(+contact)*($v*1.0)</Type>
> >   <Type match="null" />
> >   <Path match="null" />
> >   <MediaType match="any" />
> > </Service>
> >
> > <Service priority="9999">
> >   <Type select="true">xri://+i-service*(+forwarding)*($v*1.0)</Type>
> >   <Type match="null" />
> >   <Path match="non-null" />
> >   <MediaType match="any" />
> > </Service>
> >
> >
> > =wil (http://xri.net/=wil)
> >
> >
> > > -----Original Message-----
> > > From: Steven Churchill [mailto:steven.churchill@xdi.org]
> > > Sent: Tuesday, August 15, 2006 8:10 AM
> > > To: Tan, William; xri@lists.oasis-open.org
> > > Subject: RE: [xri] FW: Service selection
> > >
> > >
> > > Wil,
> > >
> > > Does your proposal below satisfy the use case presented by our I-
> Service
> > > configuration (see
> > > http://iss.xdi.org/moin.cgi/IserviceEndpointDefinitions).
> > >
> > >
> > > That is, does it allow specifying the following selection criteria:
> > >
> > > 1. 	Select the contact service (a) nothing else is selected (b)
> no type
> > > is specified and (c) the path is empty.
> > >
> > > and
> > >
> > > 2.	Select the forwarding service if (a) nothing else is selected (b)
> > > no
> > > type is specified and (c) the path is non-empty.
> > >
> > > Does your proposal allow expressing the above?
> > >
> > > > -----Original Message-----
> > > > From: Tan, William [mailto:William.Tan@neustar.biz]
> > > > Sent: Thursday, August 03, 2006 9:35 PM
> > > > To: xri@lists.oasis-open.org
> > > > Subject: [xri] FW: Service selection
> > > >
> > > > Ideally, I would like to remove the IF statements so that the
> service
> > > > selection process can be modeled with just a chain of map and filter
> > > > operations.
> > > >
> > > > So, concrete proposal:
> > > > 1. Do NOT add match="default" elements (8.2.1). If it's optional it
> > can
> > > be
> > > > made explicit reducing one step from the spec.
> > > > 2. Remove match="none". The placement of this attribute is awkward;
> it
> > > > should be modeled as an attribute of Service if we really needed it.
> > If
> > > > anyone has a compelling use case for it please speak up.
> > > > 2. Remove match="default" altogether. I understand that this is used
> > as
> > > a
> > > > default match if no other services match. However, I think the same
> > can
> > > be
> > > > achieved by creating a Service with null priority (lowest) and has:
> > > > <Type match="any"/>
> > > > <Path match="any"/>
> > > > <MediaType match="any"/>
> > > >
> > > > This may not be the most descriptive way to do it, but if it can
> take
> > > care
> > > > of most use cases I'm willing trade it for a simpler service
> selection
> > > > process.
> > > >
> > > >
> > > > =wil (http://xri.net/=wil)
> > > >
> > > > -----Original Message-----
> > > > From: Gabe Wachob [mailto:gabe.wachob@amsoft.net]
> > > > Sent: Friday, August 04, 2006 6:34 AM
> > > > To: Tan, William; drummond.reed@cordance.net; Chasen, Les; 'Steve
> > > > Churchill'; 'Victor Grey'
> > > > Subject: RE: Service selection
> > > >
> > > > What exactly would you propose? I find all this service selection
> > stuff
> > > to
> > > > be the most confusing and complicated stuff, so I've resigned myself
> > to
> > > > not
> > > > memorizing the actual process in great detail, and simply hope that
> it
> > > > doesn't meet too much pushback from others who find it confusing
> like
> > > > myself.
> > > >
> > > > So if you have a concrete proposal to simplify, I'm all for it.
> > > >
> > > > BTW, apparently the email list is back up.
> > > >
> > > >    -Gabe
> > > >
> > > > -----Original Message-----
> > > > From: Tan, William [mailto:William.Tan@neustar.biz]
> > > > Sent: Thursday, August 03, 2006 8:22 AM
> > > > To: drummond.reed@cordance.net; Gabe Wachob; Chasen, Les; Steve
> > > Churchill;
> > > > Victor Grey
> > > > Subject: FW: Service selection
> > > >
> > > > Last one.
> > > >
> > > > =wil (http://xri.net/=wil)
> > > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Tan, William
> > > > Sent: Wednesday, August 02, 2006 6:11 PM
> > > > To: xri@lists.oasis-open.org
> > > > Subject: Service selection
> > > >
> > > > We should be able to express the service selection process using a
> > > series
> > > > of
> > > > functions that operate on a list.
> > > >
> > > > Here's some pseudo python code that implements how I interpreted the
> > > spec:
> > > >
> > > > # 8.3 #1 - discard services with a child element with match="none"
> > > > services = filter(matchIsNotNone, services)
> > > >
> > > > # 8.2.1 #1 - add missing Type/Path/MediaType elements with
> > > match="default"
> > > > services = map(addMatchDefaults, services)
> > > >
> > > > # 8.2.1 #3 and #4 - apply rules for match=(content|any|null|non-null)
> > > > #                   removing Type/Path/MediaType elements that do
> not
> > > > match
> > > > services = map(matchContent, services)
> > > >
> > > > # 8.2.1 #4 - find any remaining <Type match!="default"> elements
> > > > if matchedServices.any(findTypeMatch)
> > > >         # remove all elements with <Type match="default">
> > > >         services = map(removeTypeMatchDefaults, services)
> > > >
> > > > # repeat above for Path
> > > > if matchedServices.any(findPathMatch)
> > > >         services = map(removePathMatchDefaults, services)
> > > >
> > > > # repeat above for MediaType
> > > > if matchedServices.any(findMediaTypeMatch)
> > > >         services = map(removeMediaTypeMatchDefaults, services)
> > > >
> > > > # 8.3 #2 and #3 - apply selection rules
> > > > return services.filter(canSelect)
> > > >
> > > >
> > > > Note that 8.3 is done first in order to filter out inactive services.
> > > > Also,
> > > > this process actually tinkers with the nodes within the services. In
> > > > reality, we would store the indices of the matching services and
> > return
> > > > the
> > > > copies in the original XRD.
> > > >
> > > > I would also like to get rid of the "if" statements above without
> too
> > > much
> > > > taekwondo. You can reduce it to a single loop to find all three
> > matching
> > > > elements, but is just an optimization.
> > > >
> > > > Does anyone have any suggestions? I strongly feel that if we can
> solve
> > > > this
> > > > function programming piece, it'll help us refactor the spec to be
> more
> > > > succinct.
> > > >
> > > >
> > > > =wil (http://xri.net/=wil)
> > > >
> > > >
> > > >
> > >
>