Re: Multiple Addresses in an EPR

Conor P. Cahill wrote:

>On a technical basis, I haven't heard anyone say that this isn't
>a resonable use case.
>  
>
I think it is a reasonable use case and I suspect others do to. I just 
don't believe it is necessary to cope with it within WS-A by requiring 
changes to the specification.

> > 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).
>  
>
And apart from the "inefficiencies" that you may find in your specific 
environment, this is fine and well within scope. And it's interoperable too.

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

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

Received on Monday, 17 October 2005 09:32:06 UTC