Test Cases, Interop, Closure

["Wachob, Gabe" <gwachob@visa.com>]

Drummond's proposed change pushes me even more strongly to suggest that
we come up with a good number of test cases concurrently with pushing
this draft to finalization. This will ensure: 

A) that we all actually understand this specification (esp the service
selection part)

B) that we believe the wording is understood the same way

C) that we are prepared to interop test with a set of agreed-upon
interop tests 

Not that long ago, I proposed a Feb 28th date to hold a set of interop
tests. Wild fantasy, I know, given that its already Feb 21. I hoped we'd
have been more done with the drafts by now, but it looks like we are
finally getting close. Hopefully we'll be able to set up a more
realistic date soon. At the VERY LEAST, I hope that we can show a baked
spec and demonstrate interop by the May 9th OASIS Symposium in San
Francisco (hopefully MUCH earlier). I don't know that we'll do anything
formal, but I think with the attention on OASIS, it would behoove us to
have our work all but wrapped on these important specs. 

Can someone (hopefully one of the implementers) step up and start
putting together some test cases (on this path selection part if nothing
else) on the wiki? For path selection, I'm thinking a set of QXRIs, a
set of XRDs and the "results" of applying the path selection algorithm
to the various XRDs with each QXRI. 

http://wiki.oasis-open.org/xri/TestCases

This should also be valuable input for the non-normative guide document
that is mentioned in wd10ed05 (why did we get into numbering this way?
Isn't this just wd10 or wd11?)

	-Gabe

> -----Original Message-----
> From: Drummond Reed [mailto:drummond.reed@cordance.net] 
> Sent: Tuesday, February 21, 2006 5:06 PM
> To: xri@lists.oasis-open.org
> Subject: [xri] 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 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all 
> your TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr
oups.php 
> 
>