[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Proposal for "select" attribute
The first of several action items from yesterday's TC call, this is a proposal to add a "select" attribute to the XRI Resolution 2.0 Working Draft 10 spec. The problem this solves is that in Editor's Draft 06, the value of "only" for the match attribute is an exception to the rule that all values of the match attribute apply to what should be matched for that element. In other words, "content", "any", "non-null", "null", and "none" describe WHAT should match. But "only" describes WHAT SHOULD HAPPEN if there is a match. Steve felt that having this exception made "grokking" the match rules much more difficult. There was consensus on the call that this was true and that we should fix it. I exchange emails with Steve last night and our proposal to solve this problem is to remove the "only" value of the match attribute and instead having a second Boolean attribute called "select". The default would be "false", i.e., this is the implied value if the attribute if absent or its value is null. If select="true", then the parent element is automatically selected if the element is matched. In words, the purpose of the select attribute is to override the default rule that in order to be selected a service endpoint must match across all three elements (Type, MediaType, and Path). Besides being cleaner and easier to understand, the select attribute also has the advantage that it can be used in conjunction with any value of the match attribute, i.e., select="true" can be used not just with the default value of match="content", but also with match="null" for example. Examples: <Service> <ProviderID>xri://!!1000</ProviderID> <Type select="true" >xri://+authentication*($v*1.0)</Type> <Path select="true" >(+authentication)</Path> <URI>http://some.i-service.biz/(+authn)*($v*1.0)/(=!1234.5678)</URI> </Service> <Service> <ProviderID>xri://!!1000</ProviderID> <Type select="true" >xri://+contact*($v*1.0)</Type> <Path match="null" select="true" /> <URI>http://some.i-service.biz/(+contact)*($v*1.0)/(=!1234.5678)</URI> </Service> If these service endpoints are in the XRD returned for "xri://@foo", then: 1) xri://@foo/(+authentication) would match the first service even though there is no Type match because select="true" on Path. 2) xri://@foo?_xrd_t=xri://+authentication*($v*1.0) would match the first service even though there is no Path match because select="true" on Type. 3) xri://@foo would match the second service even though there is no match on Type because the Path is null and select="true". This change will go into Editor's Draft 07 unless anyone posts objections/revisions to the list. Thanks, =Drummond
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]