Re: Multiple Addresses in an EPR

+1

Rogers, Tony wrote:

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

-- 
Mark Little
Chief Architect
Arjuna Technologies Ltd
www.arjuna.com

Received on Monday, 17 October 2005 09:23:08 UTC