W3C home > Mailing lists > Public > xml-dist-app@w3.org > February 2004

Re: Proposed resolution to issue 455

From: Marc Hadley <Marc.Hadley@Sun.COM>
Date: Fri, 27 Feb 2004 16:32:18 -0500
To: Martin Gudgin <mgudgin@microsoft.com>
Cc: Jacek Kopecky <jacek.kopecky@systinet.com>, XMLP Dist App <xml-dist-app@w3.org>
Message-id: <6B6225E4-696C-11D8-A5A2-000A95BC8D92@Sun.COM>
On Feb 26, 2004, at 2:51 PM, Martin Gudgin wrote:
>>> But surely such a URI would be refer "to the 'none' header block in
>>> some way"
>> I was thinking more along the lines of another header block
>> whose semantics specifically enable one or more
>> Representation headers. You could say that any header that
>> contains a URI that matches the URI of the Representation
>> header does that implicitly but the linkage seems rather
>> weak. This would also mean that you couldn't support the use
>> case in the issue:
>>> "If I want to specifically cause two different
>> representations, of the
>>> same media type for the same resource, to be sent to A and B
>>> respectively, can I safely use multiple representation headers that
>>> differ in their soap:roles to do this?  I would think so."
>> If both Representation header blocks are in scope how could I
>> target them ?
> In that case surely you would just target rep1 at A and rep2 at B.
> What's the problem?
Two different representations of the same resource would have the same 
URI. If a Representation header block is is scope for URI resolution 
regardless of whether the node is playing the role it is targeted at 
(e.g. if its role was 'none') then both Representation headers would 
show up when you try to resolve. Which do you pick, how do you target ?

Or are you suggesting that a Representation header block targeted at 
'none' is somehow different (wrt to processing semantics) to a 
Representation header block targeted at some other role the node isn't 
playing ?


Marc Hadley <marc.hadley at sun.com>
Web Products, Technologies and Standards, Sun Microsystems.

Received on Friday, 27 February 2004 16:30:03 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:25 UTC