- From: Conor P. Cahill <concahill@aol.com>
- Date: Sun, 16 Oct 2005 20:09:15 -0400
- To: "Rogers, Tony" <Tony.Rogers@ca.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>
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 00:09:54 UTC