[ogsa-wg] Re: [ogsa-naming-wg] ... without wsa:Address profil e, AbstractName is meaningless ...

[Steve Loughran]

Maguire_Tom at emc.com wrote:
>  
> 
> 
>>And if so, is everyone expected to (a) have read and understood 
>>section 3.2.3. on the subject of URI equivalence(below), or (b) 
>>to explicitly require case-sensitive-string-matching as the comparison.
> 
> 
> I think logically (a) but since they SHOULD be IRIs I would use section 5 of
> RFC 3987 (below). Which basically adds codepoint normalization to the URI
> normalization you ref'd in section 3.2.3.
> 
> The point being that we should be EXCEPTIONALLY clear about what it means to
> be equivalent.  Perhaps we should even right a few TEST CASES. :-)


oh, this is good, nice simple case-sensitive comparisons, albeit after 
escaping logic is applied. Presumably WSDM ResourceIds must be compared 
this way?

right now, the only way I compare equivalence is via resourceIDs, 
because there is no guarantee that different urls match to different 
things. I think, following the discussions here, that it is possible to 
tack in an abstract name element into a WS-A EPR, but I have some concerns.

1. right now, nobody's WS-A stacks interoperate properly with anything 
other than the address field. I am currently trying to debug Axis2's 
handling of path?query  handling in that URL, so am not convinced the 
toolkits intra-operate with their own implementations properly.

2. if you have a unique name metadata in a request, then that name could 
get out of sync with the thing at the end, unless the name came in every 
request and the endpoint validated it. So we'd really have to formalise 
that for naming

- the unique name parameter has to be supplied as mustUnderstand=true
- the endpoint checked it and failed if it was at odds with the rest of 
the request

The best way to do these is to use only the unique name to do internal 
dispatch of requests to resources.

Now if you will excuse me, axis2 has just rebuilt, I have some single 
stepping through dispatching to do...

-steve