I thought the CR phase was about figuring out whether the spec could be
implemented 'as written'...
Gudge
> -----Original Message-----
> From: public-ws-addressing-request@w3.org
> [mailto:public-ws-addressing-request@w3.org] On Behalf Of
> Conor P. Cahill
> Sent: 16 October 2005 18:39
> 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, 9:02 PM:
>
> > 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.
>
> That's what the CR process is about. If one can't raise issues
> and get them resolved, then there doesn't need to be a CR phase
> at all.
>
> On a technical basis, I haven't heard anyone say that this isn't
> a resonable use case.
>
> > 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.
>
> So you're telling me that CA and other implementors will commit to
> adopt one that I choose to describe now? I'm guessing not. I'm
> guessing that there will be many toolkits that either a) don't
> support this functionality at all because it isn't in the spec,
> or b) choose to do it in a different non-interoperable way.
>
> >
> > "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.
>
> A) My comment was more related to trying to follow the spec as
> written since that is all that out-of-the-box toolkits will
> be able to do). The spec currently requires that the physical
> address be carried in a single wsa:Address element. So if I
> wanted to follow the spec and I had multiple addresses I would
> have to have multiple EPRs (othewise I risk that clients
> built off the spec will not recognize the alternative addresses).
>
> B) Given that a spec has an xs:any in the EPR, I could put the
> kitchen sink in there, so there's pretty much no problem that
> would be impossible to resolve. That doesn't mean that there
> aren't good reasons to have defined elements (which is why,
> even though there is an xs:any, the spec does define Address,
> ReferenceParameters, and Metadata).
>
> Conor
>
>
>
>