RE: Multiple Addresses in an EPR

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
sympathetic.


Tony Rogers
tony.rogers@ca.com

-----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;
WS-Addressing
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
interoperable.

 > 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
address).

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.

Conor

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