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 03:31:00 UTC