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