- From: David Booth <dbooth@w3.org>
- Date: Wed, 24 Nov 2004 11:53:34 -0500
- To: Martin Gudgin <mgudgin@microsoft.com>
- Cc: David Orchard <dorchard@bea.com>, Jonathan Marsh <jmarsh@microsoft.com>, public-ws-addressing@w3.org
Gudge, On Mon, 2004-11-22 at 10:10, Martin Gudgin wrote: > . . . [URI+RefProps/Params] is no more ( or less ) of > an implementation choice than using; > > URIs with more than just a domain name > URIs with query params > . . . . I disagree and agree. It depends on the URIs. I agree that URI+RefParams exposes the implementation model to the same extent as URI with QueryParams. (RefParams are equivalent to cookies, and cookies expose the implementation model to the same extent as QueryParams, though they differ markedly in other characteristics, such as Web friendliness.) I also agree that if URI+RefProps is restricted to have no path in the URI part, then URI+RefProps exposes the implementation model to the same extent as a URI with path. (Though again, they differ markedly in other characteristics.) But if URI+RefProps *has* a path in the URI part, then URI+RefProps clearly expose the implementation model more than just a URI with a path. Consider the two examples: URI with path: http://example.com/a/b/c/d/e/f/ URI+RefProps: http://example.com/a/b/c <RefProps><d /><e /><f /></RefProps> In the first example the service *might* internally use a two-part dispatch mechanism, based first on the http://example.com/a/b/c part and then on the d/e/f part, but it isn't at all clear that it does. It is far more evident that the second example does. -- David Booth W3C Fellow / Hewlett-Packard
Received on Wednesday, 24 November 2004 16:53:45 UTC