RE: [xri] FW: Service selection

["Steven Churchill" <steven.churchill@xdi.org>]

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