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

RE: Multiple Addresses in an EPR

From: Rogers, Tony <Tony.Rogers@ca.com>
Date: Mon, 17 Oct 2005 11:02:03 +1000
Message-ID: <7997F38251504E43B38435DAF917887F58EA1E@ausyms23.ca.com>
To: "Conor P. Cahill" <concahill@aol.com>
Cc: "David Orchard" <dorchard@bea.com>, "John Kemp" <john.kemp@nokia.com>, "ext Mark Little" <mark.little@arjuna.com>, "Mark Nottingham" <markn@bea.com>, "WS-Addressing" <public-ws-addressing@w3.org>

So I would prefer that those who have this newly discovered need can
choose to solve it in one of the other ways that you have outlined,
rather than hold back a standard that is in CR phase already - yes.
Making the change that you propose would drag the spec back to LC again,
and delay it for everyone.

Your fear that there will be a variety of implementations may be
groundless - if you choose one and describe it now, then others can
follow your lead, and all will be well.

"Not having this capability makes it very hard/inefficient to support a
real world use of the spec."

Not true - you have described multiple ways in which you might implement
a solution, and they appear both simple and efficient (perhaps not as
aesthetically pleasing). If there were truly no way in which the problem
might be addressed, other than changing the spec, then I would be more

Tony Rogers

-----Original Message-----
From: Conor P. Cahill [mailto:concahill@aol.com] 
Sent: Monday, 17 October 2005 10:09
To: Rogers, Tony
Cc: David Orchard; John Kemp; ext Mark Little; Mark Nottingham;
Subject: RE: Multiple Addresses in an EPR

Rogers, Tony wrote on 10/16/2005, 7:50 PM:

 > I strongly prefer DaveO's solution (put the extra addresses into an
> extension) over the idea of making the address field unbounded.

So you prefer that everybody who choose to do this could do it in a
different way (some in metadata, some in additional EPR child elements,
all with different names unless they happened to get
lucky) and you prefer to store the *same* information in two diferent
locations within an EPR?

That doesn't make sense to me from a "good enginering" point of view.
A spec is there so that people do things in an interoperable,
predictable way.   Putting the data in a profile chosen, extension
area makes it very likely that different instances of this will not be

 > There will be a great many implementations using a single address
(most  > of the use-cases I've encountered so far will use a single

I agree that there are many that will use a single address.  I think
that there will be many more cases that people have throught of so far
that will take advantage of being able to use multiple addresses.

This feedback you are getting is from someone who is *implementing*
this stuff to put it into production.   This isn't just an "it
would be nice" request.  Not having this capability makes it very
hard/inefficient to support a real world use of the spec.

Received on Monday, 17 October 2005 01:04:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:28:29 UTC