- From: Katy Warr <katy_warr@uk.ibm.com>
- Date: Wed, 6 Jan 2010 09:53:19 +0000
- To: Asir Vedamuthu <asirveda@microsoft.com>
- Cc: Asir Vedamuthu <asirveda@microsoft.com>, Gilbert Pilz <gilbert.pilz@oracle.com>, "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>, public-ws-resource-access-request@w3.org
- Message-ID: <OFA2B5221A.6BF982D3-ON802576A3.00359342-802576A3.0036524A@uk.ibm.com>
Asir Thank you for the updated proposal. I noticed that you changed the TNS of the feature WSDL that is also specified as the 'Identifier' value. For example, in 8,3: (14) <mex:MetadataSection (15) Dialect='http://schemas.xmlsoap.org/wsdl/' (16) Identifier='http://services.example.org/stockquote/ws-tra'> (17) <mex:MetadataLocation> (18) <!?- Reference to WS-Transfer WSDL at the Metadata Endpoint --> (19) http://services.example.org/stockquote/metadata/TransferWSDL (20) </mex:MetadataLocation> If the ws-transfer operations are exposed on WSDL that does not have the standard W3C namespace, surely the operations exposed on that WSDL are not spec compliant? Many thanks Katy From: Asir Vedamuthu <asirveda@microsoft.com> To: Asir Vedamuthu <asirveda@microsoft.com>, Katy Warr/UK/IBM@IBMGB, Gilbert Pilz <gilbert.pilz@oracle.com> Cc: "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org> Date: 05/01/2010 16:19 Subject: RE: Bug 6463: Attaching Policy to WS-Mex GetMetadata - Marked up proposal The attached Word document carries all the known editorial suggestions [1][2]. [1] http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Dec/0067.html [2] http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Dec/0076.html Regards, Asir S Vedamuthu Microsoft Corporation From: public-ws-resource-access-request@w3.org [ mailto:public-ws-resource-access-request@w3.org] On Behalf Of Asir Vedamuthu Sent: Tuesday, December 15, 2009 12:45 PM To: Katy Warr Cc: public-ws-resource-access@w3.org Subject: RE: Bug 6463: Attaching Policy to WS-Mex GetMetadata - Marked up proposal Thanks Katy for your response. Reviewed. We suggest the following editorial amendments. We did not have sufficient time to prepare a marked up version. We will be happy to prepare one. 1. Example 8-1 Katy> We can exploit the fact that the WS-Metadata Endpoint is the same as the application endpoint (that the EPR represents) and therefore would share its protocol binding information. Given that section 8 is about bootstrap binding, to help our readers, we think these assumptions should be called out explicitly. Suggestion s/Example 8-1, a [WS-Addressing] endpoint reference to a service endpoint contains the metadata to allow requesters to issue a GetMetadata request against it./Example 8-1, a [WS-Addressing] endpoint reference to a service endpoint contains the metadata to allow requesters to issue a GetMetadata request against it. Example 8-1 assumes that requestors are aware of binding information such as the version of SOAP and the underlying transport./ 2. Example 8-1 - replace necessary metadata with additional metadata Example 8-1 illustrates how to embed additional metadata. Suggestion s/ The endpoint reference contains metadata associated with the service endpoint (lines 04-19) and a MetadataSection (lines 06-18) which contains the necessary metadata for interacting with the endpoint through [WS-MetadataExchange]./ The endpoint reference contains metadata associated with the service endpoint (lines 04-19) and a MetadataSection (lines 06-18) which contains additional metadata for interacting with the endpoint through [WS-MetadataExchange]./ 3. Drop the last sentence. We think this is a cut and paste error. The last sentence talks about an alternative that is already discussed as example 8-2. Suggestion s/ As an alternative to using MetadataLocation (lines 17-20), the WS-MetadataExchange WSDL containing the appropriately attached policy could have been embedded directly into the MetadataSection.// 4. Example 8-2 Katy> I have made some minor changes (the Identifier and tns on line 10 - let me know if I got this wrong) The embedded WSDL is a user-defined WSDL and constructs should not be in the MEX namespace name. Suggestions s/"targetNamespace='http://www.w3.org/2009/09/ws-mex'"/"targetNamespace='http://services.example.org/stockquote/metadata'"/ (or any other namespace name other than the MEX namespace name) s/"Identifier='http://www.w3.org/2009/09/ws-mex'"/"Identifier='http://services.example.org/stockquote/metadata'"/ s/The metadata for the [WS-MetadataExchange] interaction is of wsdl dialect (line 11) and the identifier (line 08) identifies the WS-MetadataExchange feature as described in section 9"// 5. Example 8-3 The same reasoning as item 4 applies to Example 8-3. Suggestions s/"Identifier='http://www.w3.org/2009/09/ws-tra'"/"Identifier='http://services.example.org/stockquote/ws-tra'"/ (or any other namespace name other than the Transfer namespace name) s/The metadata for the [WS-MetadataExchange] interaction is of wsdl dialect (line 16) and the identifier (line 17) identifies the WS-Transfer feature as described in section 9./The metadata for the [WS-MetadataExchange] interaction is of wsdl dialect (line 16)./ Regards, Asir S Vedamuthu Microsoft Corporation From: Katy Warr [mailto:katy_warr@uk.ibm.com] Sent: Tuesday, December 15, 2009 3:07 AM To: Asir Vedamuthu Cc: public-ws-resource-access@w3.org Subject: RE: Bug 6463: Attaching Policy to WS-Mex GetMetadata - Marked up proposal Hi Asir Thanks for your comments. > We are afraid that the proposed Example 8-1 does not provide sufficient protocol binding information to allow requesters to issue a GetMetadata request against a service endpoint. For instance, how can a requester infer what is the version of SOAP? What is the underlying protocol transport? We can exploit the fact that the WS-Metadata Endpoint is the same as the application endpoint (that the EPR represents) and therefore would share its protocol binding information. Hence, in this case, I don't think we require this information (it may be defaulted to). > We think that the WS-MetadataExchange specification should provide an example that provides sufficient binding information, including policies (to address issue 6463), to bootstrap. > The description of the alternative sounds right. But, example 7.1 describes how to embed service metadata within an EPR. These are two different use cases. It might help to show case an example that illustrates how to embed a bootstrap binding in an EPR and how to attach a policy expression (to address issue 6463) to the bootstrap binding. How about the attached update? I've taken your example (from a previous email) and included it as example 8.2. I have made some minor changes (the Identifier and tns on line 10 - let me know if I got this wrong). I've also added so explanation below the example for your review/comments and made some very minor tweaks to the other explanations to ensure that the explanations were consistent and that the text flows ok. Regards, Katy From: Asir Vedamuthu <asirveda@microsoft.com> To: Katy Warr/UK/IBM@IBMGB, "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org> Date: 14/12/2009 17:13 Subject: RE: Bug 6463: Attaching Policy to WS-Mex GetMetadata - Marked up proposal Thanks Katy. Here are some initial comments on the proposal. >In Example 8-1, a [WS-Addressing] endpoint reference to a service endpoint contains the metadata to allow requesters to issue a GetMetadata request against it We are afraid that the proposed Example 8-1 does not provide sufficient protocol binding information to allow requesters to issue a GetMetadata request against a service endpoint. For instance, how can a requester infer what is the version of SOAP? What is the underlying protocol transport? We think that the WS-MetadataExchange specification should provide an example that provides sufficient binding information, including policies (to address issue 6463), to bootstrap. >As an alternative to using MetadataLocation (lines 08-17), the WS-MetadataExchange WSDL containing the appropriately attached policy could have been embedded directly into the MetadataSection. The embedded WSDL approach was used in example Example 7.1 to pass metadata in the EPR. The description of the alternative sounds right. But, example 7.1 describes how to embed service metadata within an EPR. These are two different use cases. It might help to show case an example that illustrates how to embed a bootstrap binding in an EPR and how to attach a policy expression (to address issue 6463) to the bootstrap binding. We will be more than happy to work with Katy to prepare a revised proposal. Regards, Asir S Vedamuthu Microsoft Corporation From: public-ws-resource-access-request@w3.org [ mailto:public-ws-resource-access-request@w3.org] On Behalf Of Katy Warr Sent: Monday, December 07, 2009 10:42 AM To: public-ws-resource-access@w3.org; Asir Vedamuthu Subject: Bug 6463: Attaching Policy to WS-Mex GetMetadata - Marked up proposal Following my action to create a markup version of the proposal for bug http://www.w3.org/Bugs/Public/show_bug.cgi?id=6463, please find the marked up document attached. The changes are all in Section 8 (and an example is moved from section 7). Asir, The difference between your example and my previous one is primarily that you have embedded the WSDL metadata within the EPR, rather than using Policy Attachments. Whilst both approaches work, I believe that we should have a wider variation of examples within the specification in order to illustrate different features and usage scenarios. From my experience, a wide range of examples is of great benefit to developers. Embedded WSDL is already illustrated in example 7-1. In this particular example (8.1), policy attachments also work very well as it provides a mechanism to associate policy with a single operation without having the whole WSDL included within the EPR. As a suggested compromise, I've included the policy attachments example (8-1) in the proposal attached to this mail, but added a detailed explanation below it in order to aid understanding. I have also added some text to say that the WSDL could be embedded, as an alternative approach. Regards Katy Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU [attachment "wsmex sections 7 and 8 for 6463-v03.doc" deleted by Katy Warr/UK/IBM] Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Received on Wednesday, 6 January 2010 09:53:59 UTC