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

Received on Monday, 17 October 2005 01:39:57 UTC