[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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) > > > > > > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]