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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

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