RE: Multiple Addresses in an EPR

There are 2 important points worth talking about: the process that the
WS-A operates under in W3C, and the technical merits of the request.

The process has allowed for review of the documents for quite some time,
and even calls out a "Last Call" for review.  CR is very late in the
process.  Only critical changes, such as something that is
unimplementable or heinously broken, should be done to put the doc back
into LC then another CR period.

Having said that, BEA has been a fan of "backup" addresses for quite
some time.  We proposed this for wsdl 2.0 include/import, which became
issue 129 [1].  The WSDL WG decided against adopting it for WSDL 2.0

It appears that W3C working groups, from WSDL to WS-Addressing to XML
Schema to XInclude to XLink (and the song goes on..) have consistently
decided to not allow for fallback or alternative addresses.  IMO, that
architectural decision is fairly ironic because the general knock on
pre-Web service technologies is that they assume the network isn't there
and so communication is reliable.  

As much as I find this architectural situation disagreeable, I believe
that the W3C groups have provided a consistent architectural treatment
of addresses and a change to WS-A on the technical merits of the
multi-address proposal is not warranted.  Further, it is certainly not
worth delaying WS-Addressing by months and quarters to add this feature
in.  I suppose the W3C TAG could look at the role of network failure in
provide web addresses, but I'm not sure about that line of approach.

Cheers,
Dave

[1]
http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/ws/desc/issues/wsd-issues.h
tml#x129

> -----Original Message-----
> From: John Kemp [mailto:john.kemp@nokia.com]
> Sent: Sunday, October 16, 2005 8:30 PM
> To: ext Martin Gudgin
> Cc: Conor P. Cahill; Rogers, Tony; David Orchard; ext Mark Little;
Mark
> Nottingham; WS-Addressing
> Subject: Re: Multiple Addresses in an EPR
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I certainly appreciate the process-oriented viewpoint. Processes, of
> course, are supposed to work for those who create and adhere to them.
> And they're there to make sure the specification that gets produced is
> not just implementable, but sound from an engineering perspective.
> Furthermore, the most compelling reason to make a standard at all (IMO
> at least) is for interoperability.
> 
> "standards sausage" - v. good ;)
> 
> - - JohnK
> 
> ext Martin Gudgin wrote:
> > To me, it's about figuring out whether people can implement the spec
'as
> > written'. Part of getting the spec to CR in the first place is
ensuring
> > it meets the requirements specified in usage scenarios etc. Few
specs do
> > everything everyone wants them to do. Sometimes features are left
out
> > for a variety of reasons ( same with shipping any 'product' really
). I
> > believe this particular 'reasonable usage' was discussed by the WG
and,
> > essentially, didn't make the 80/20 cut. And I think the discussion
> > occurred before Last Call, let alone CR.
> >
> > It's easy to cut features when moving forward from CR. It's very
hard (
> > impossible? ) to add features without incurring signficant extra
process
> > ( i.e. going back to Last Call ).
> >
> > To me, before ( or during ) Last Call was the right time to ask for
this
> > feature to be added. Not during CR. And in some cases, people ask
for
> > features to be added, and the WG still declines to add them...
That's
> > just part of the way standards sausage gets made...
> >
> > Gudge
> >
> >
> >>-----Original Message-----
> >>From: John Kemp [mailto:john.kemp@nokia.com]
> >>Sent: 16 October 2005 19:33
> >>To: Martin Gudgin
> >>Cc: Conor P. Cahill; Rogers, Tony; David Orchard; ext Mark
> >>Little; Mark Nottingham; WS-Addressing
> >>Subject: Re: Multiple Addresses in an EPR
> >>
> > ext Martin Gudgin wrote:
> >
> >>I thought the CR phase was about figuring out whether the
> >
> > spec could be
> >
> >>implemented 'as written'...
> >
> > Isn't it also about figuring out whether the spec. is
> > interoperable for
> > reasonable usage? I've heard a reasonable usage expressed that isn't
> > supported interoperably by WS-A.
> >
> > - JohnK
> >
> >
> >>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
> >
> >
> >
> >
> >
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (Darwin)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
> 
> iD8DBQFDUxrEmNJiOOM57NMRAt05AKCWmgyJCNKFCHP65C7vHkfDLuU6/wCg+ETR
> Hjm17ZSrsAXb2Et+IvrDSY0=
> =0xcq
> -----END PGP SIGNATURE-----

Received on Monday, 17 October 2005 05:47:41 UTC