Maguire_Tom@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