Re: WS-Addr issues

Dave, I agree to some degree. However, there are two extremes:

(i) lets' do absolutely nothing to the spec. as it stands. The 
advantage is that this group comes in with a standard that is way under 
the original delivery date. The disadvantage is that it doesn't address 
all user requirements. Let's be frank: there are a lot of users 
represented by companies at this group that weren't represented by the 
companies who drew up the charter and original submission. So we'd be 
doing them a disservice.

or

(ii) we change everything. The advantage is that we get something that 
is perhaps a more pure (?) specification and (potentially) pleases 
everyone all of the time. The disadvantage is that it takes a long time 
to do (c.f. WS-Arch).

My preference is for something in between, lending more for (i) than 
(ii). This isn't an academic exercise and we do have time constraints. 
However, within those constraints we should look at as many issues as 
we can that most of us think are contentious. If we place hard 
deadlines on discussion/addressing each of those issues we should still 
be able to time manage this to everyone's satisfaction.

Mark.

On 5 Nov 2004, at 18:27, David Orchard wrote:

>
>
> You did sign up for a WG that is a Fast-Track and that has 1 member
> submission as the basis, not 2 member submissions.
>
> I can understand making some changes to the spec, even potentially
> adding new components (timeout?) or changing cardinalities or some
> refactoring.  But the composite set of changes being talked about does
> not jive with the charter on timeline or starting point.
>
> I believe that we have done a disservice to our customers by the length
> of time it has taken us to do SOAP 1.2 and WSDL 2.0.  The length of 
> time
> has seriously hindered current and future deployment of these RF
> standards driven technologies.  Should we break our charter 
> requirements
> and do a lengthy WS-Addressing, I truly believe that the world will
> simply just use the WS-Addressing member submission and not move the
> WS-A Recommendation.  I believe this concern partially led to the
> charter being created the way it is.
>
> Cheers,
> Dave
>
>> -----Original Message-----
>> From: Anish Karmarkar [mailto:Anish.Karmarkar@oracle.com]
>> Sent: Thursday, November 04, 2004 4:50 PM
>> To: David Orchard
>> Cc: Jim Webber; Francisco Curbera; Marc Hadley; Mark Little;
> public-ws-
>> addressing@w3.org; public-ws-addressing-request@w3.org; Savas
> Parastatidis
>> Subject: Re: WS-Addr issues
>>
>> David Orchard wrote:
>>
>>> With:
>>> - Jim wanting to get rid of ref props/params and Action (and by
>>> extension I'm wondering if messageid and relatesTo should be removed
>>> IHO),
>>> - Marc wanting to add lifecycle to EPRs and make To Optional,
>>> - Anish wanting to make Service Qname required for EPRs, Address
>>> optional,
>>> Action a child of To:,
>>> - Glen wanting ref props/params as child of To:,
>>>
>>> This feels to me like some people want to start from scratch.  I
> don't
>>> think I signed up for a WS-Addressing 2.0 that will take N years.
>>>
>>
>> As opposed to rubber-stamping of current WS-Addressing spec with ed.
>> changes ;-)
>>
>> -Anish
>> --
>>
>>> Dave
>>>
>>>
>>>> -----Original Message-----
>>>> From: public-ws-addressing-request@w3.org
>>>
>>> [mailto:public-ws-addressing-
>>>
>>>> request@w3.org] On Behalf Of Jim Webber
>>>> Sent: Thursday, November 04, 2004 1:47 PM
>>>> To: Francisco Curbera; Marc Hadley
>>>> Cc: Mark Little; public-ws-addressing@w3.org; public-ws-addressing-
>>>> request@w3.org; Savas Parastatidis
>>>> Subject: RE: WS-Addr issues
>>>>
>>>>
>>>> Paco:
>>>>
>>>>
>>>>> Action is not part of the EPR; I guess you mean make it an
>>>>> optional message header. Still, I guess your point is like
>>>>> the one about recognizing that the <To> information may be
>>>>> carried by the transport: you do agree it must be there but
>>>>> you argue it may be found in many different places (body,
>>>>> SOAPAction, etc...). I would still disagree, however: this
>>>>> just makes everything much more complicated than is really needed.
>>>>
>>>> On the contrary it makes good sense to have addressing information
>>>
>>> like
>>>
>>>> "to" in an addressing spec. It makes less sense to have "intent" or
>>>> "dispatch" information in an addressing spec, and (controversy
> ahead)
>>>> very little sense whatsoever to have "context" information in an
>>>> addressing spec.
>>>>
>>>> So - in addition to seeing off wsa:action I would also like to see
>>>> refprops/refparams removed. Certainly people will want to populate
> the
>>>> header space with particular header blocks, but bodging this through
>>>
>>> an
>>>
>>>> addressing mechanism seems a poor factoring.
>>>>
>>>> Jim
>>>> --
>>>> http://jim.webber.name
>>>
>>>
>>>
>

Received on Saturday, 6 November 2004 08:56:12 UTC