W3C home > Mailing lists > Public > public-ws-addressing@w3.org > June 2005

Re: Another go at lc75 and lc88 language (correction)

From: Amelia A Lewis <alewis@tibco.com>
Date: Mon, 6 Jun 2005 13:50:13 -0400
To: "Savas Parastatidis" <Savas.Parastatidis@newcastle.ac.uk>
Cc: public-ws-addressing@w3.org
Message-Id: <20050606135013.7a825ac9.alewis@tibco.com>

On Mon, 6 Jun 2005 18:19:08 +0100
"Savas Parastatidis" <Savas.Parastatidis@newcastle.ac.uk> wrote:
> Why couldn't the reliability spec say something like "we use the message
> identity from WS-Addressing and we introduce this additional SOAP header
> to capture the index"? Much cleaner approach me thinks.

But it violates the WSA definition.

WSA defines the message ID to be unique.

The reliability specs effectively require message uniqueness by
associating a unique sequence identifier (repeated in multiple
messages; not legal use of a WSA message ID) with a sequence number.

It is conceivable to do this by placing structure within the message ID
URI (for instance: place sequence number as the fragment identifier)
but it implies over-specification of content (some URI schemes lack
fragment identifiers, for instance).

In short, the combination of the unique *sequence* identifier (which
must be repeated on all messages in the sequence) with a (unique-in-
sequence) identifier corresponds to the WSA definition of "unique
message identifier," but with visible internal structure.

I'd suggest that if it's to be resolved in a way that would allow
something of the sort to work, that then a URI type be defined, with
attribute-based extensibility, and the caveat that the URI alone may
not be unique.  But that may cause its own sort of breakage, depending
on how important it might be for a generic WSA processor to be able to
identify the portions of the addressing element which combine uniqely.

Amelia A. Lewis
Senior Architect
TIBCO/Extensibility, Inc.
Received on Monday, 6 June 2005 17:50:15 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:09 UTC