RE: [xri] FW: Service selection

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

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)
> >
> >
> >
>