[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Addendum to XRI Res WD10 ED05
In developing example XRDS documents to illustrate features of WD10 Editor's Draft 05 the Res spec, I ran across one type of match that was supported under the ED04 model that was not using the ED05 "match" attribute. But this was easily fixed by adding one more value for the match attribute. The proposed value is "only" and the proposed matching rule is: "If there is a match on the contents of an element where the value of the @xrd:match attribute is "only", then the service endpoint (SEP) is automatically selected even if there is not a match on any other selection element for that SEP." Following is an example of why this is needed. EXAMPLE #1: BEFORE - SEPS WITHOUT MATCH="ONLY" VALUE <Service> <ProviderID>xri://!!1000</ProviderID> <Type match="null" /> <Path match="default" /> <URI>http://some.i-service.biz/(+forward)*($v*1.0)/(=!1234.5678)</URI> </Service> <Service> <ProviderID>xri://!!1000</ProviderID> <Type>xri://+authentication*($v*1.0)</Type> <Type match="null" /> <Path>(+authentication)</Path> <Path match="null" /> <URI>http://some.i-service.biz/(+authn)*($v*1.0)/(=!1234.5678)</URI> </Service> <Service> <ProviderID>xri://!!1000</ProviderID> <Type>xri://+contact*($v*1.0)</Type> <Type match="null" /> <Path>(+contact)</Path> <Path match="null" /> <URI>http://some.i-service.biz/(+contact)*($v*1.0)/(=!1234.5678)</URI> </Service> In this XRD for "xri://@foo", the XRI... xri://@foo/bar ...only matches the first SEP because the Type is null, the Path is not null, and the Path and does not match the path for the second or third SEP. The following two XRIs... xri://@foo/(+authentication) xri://@foo/(+contact) ...match the second and third SEPs respectively because the Type is null and there is a match on the Path. The same is true of... xri://@foo?_xrd_t=xri://+authentication*($v*1.0) xri://@foo?_xrd_t=xri://+contact*($v*1.0) ...because there is a match on the Type but the Path is null. Unfortunately to get this behavior, both the second and third SEPs need to mark both the Type and the Path with match="null", which means both of them will match... xri://@foo However the desired behaviour for this last XRI is to be able to control it matching only one SEP. With the "only" value for match, this can be done. EXAMPLE #2: AFTER - SEPS WITH MATCH="ONLY" VALUE <Service> <ProviderID>xri://!!1000</ProviderID> <Type match="null" /> <Path match="default" /> <URI>http://some.i-service.biz/(+forward)*($v*1.0)/(=!1234.5678)</URI> </Service> <Service> <ProviderID>xri://!!1000</ProviderID> <Type match="only" >xri://+authentication*($v*1.0)</Type> <Path match="only" >(+authentication)</Path> <URI>http://some.i-service.biz/(+authn)*($v*1.0)/(=!1234.5678)</URI> </Service> <Service> <ProviderID>xri://!!1000</ProviderID> <Type match="only" >xri://+contact*($v*1.0)</Type> <Type match="null" /> <Path match="only" >(+contact)</Path> <Path match="null" /> <URI>http://some.i-service.biz/(+contact)*($v*1.0)/(=!1234.5678)</URI> </Service> Now, with the match="only" rule, all sample XRIs match exactly one SEP each: xri://@foo/bar ==> SEP 1 xri://@foo/(+authentication) ==> SEP 2 xri://@foo/(+contact) ==> SEP 3 xri://@foo?_xrd_t=xri://+authentication*($v*1.0) ==> SEP 2 xri://@foo?_xrd_t=xri://+contact*($v*1.0) ==> SEP 3 xri://@foo ==> SEP 3 I will add this to the final Working Draft 10 unless anyone posts to the contrary. =Drummond
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]