W3C home > Mailing lists > Public > public-ws-addressing-comments@w3.org > July 2005

RE: no mustUnderstand extensibility

From: <michael.eder@nokia.com>
Date: Mon, 18 Jul 2005 09:50:48 -0400
Message-ID: <6E2B2C4FBED4D84D80F52ECD1579D068093416@bsebe101.NOE.Nokia.com>
To: <jacek.kopecky@deri.org>
Cc: <public-ws-addressing-comments@w3.org>

Jacek,

The Working Group agreed to make the editorial change you suggested below.

Please write back to us if you would like this resolution brought forward for Director review; if we do not hear from you in two weeks, we'll assume you are satisfied with our resolution.


Kind Regards,

Michael Eder


-----Original Message-----
From: public-ws-addressing-comments-request@w3.org
[mailto:public-ws-addressing-comments-request@w3.org]On Behalf Of ext
Jacek Kopecky
Sent: June 30, 2005 03:25 AM
To: Jonathan Marsh
Cc: public-ws-addressing-comments@w3.org
Subject: RE: no mustUnderstand extensibility



Dear Jonathan, WS-Addr WG,

I understand your resolution. I still feel the specification would be
inconsistent as it is (if the wording hasn't changed), so I suggest an
editorial change instead of the bigger resolution:

Please change 
"designers should consider whether they desire standard processing per
this specification in cases where their extension is not recogonised or
understood" 
to
"designers should be aware that when their extension is not recognized
or understood, the MIH will be processed in the standard way per this
specification"

The problem is just that the use of "whether" in the current wording
leaves open and unanswered the option of "they don't desire it". My
proposed wording is more a warning than a choice.

Hope it helps,

Jacek

On Wed, 2005-06-29 at 12:09 -0700, Jonathan Marsh wrote:
> Jacek,
> 
> The Working Group found the issue you raised [1] to substantially duplicate discussion we already had as a Working Group.  While there was some support in the Working Group for defining this functionality, others felt that this would impact larger areas of design (such as bringing the reconciliation of embedded metadata with known metadata) into scope, and would be hard to specify completely at this point in WS-A's lifecycle.  Given the lack of consensus to reopen this issue, the issue was closed by the chair.
> 
> Please write back to us if you would like this resolution brought forward for Director review; if we
> do not hear from you in two weeks, we'll assume you are satisifed with our resolution.
> 
> [1] http://www.w3.org/2002/ws/addr/lc-issues/#lc68
>  
> 
> ________________________________
> 
> From: public-ws-addressing-comments-request@w3.org on behalf of Jacek Kopecky
> Sent: Tue 5/3/2005 6:54 AM
> To: public-ws-addressing-comments@w3.org
> Subject: no mustUnderstand extensibility
> 
> 
> 
> 
> Hi,
> 
> as an LC comment for WS-Addressing, it is my opinion that section 2.5 of
> the Core spec is incomplete at best.
> 
> In particular, it concludes with "designers should consider whether they
> desire standard processing per this specification in cases where their
> extension is not recogonised or understood" but what if a designer comes
> up with the answer that nope, they don't desire standard processing if
> their extension is not understood? Either the section 2.5 should be
> extended with a rationale for not allowing this scenario or a model for
> required (mustUnderstand) extensions should be devised.
> 
> For the sake of simplicity, I'd probably prefer either reusing some
> existing mechanism for that (like wsdl:required), possibly raising a W3C
> issue about the creation of a general mechanism (xml:mustUnderstand?),
> or just saying clearly and explicitly that WS-Addressing does not
> support required extensions and why.
> 
> Also, please note the typo in "recogonised" present in that text in the
> spec.
> 
> Best regards,
> 
>                    Jacek Kopecky
> 
>                    Ph.D. student researcher
>                    Digital Enterprise Research Institute
>                    University of Innsbruck
>                    http://www.deri.org/
> 
> 
> 
> 
> 
> 
> 
> 
Received on Monday, 18 July 2005 13:51:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:19:38 GMT