- From: Antoine Mensch <antoine.mensch@odonata.fr>
- Date: Thu, 13 May 2010 12:37:20 +0200
- To: Ram Jeyaraman <Ram.Jeyaraman@microsoft.com>
- CC: "public-ws-resource-access-comments@w3.org" <public-ws-resource-access-comments@w3.org>, "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
Hi Ram, I am still not convinced that the existing mechanisms will allow us to profile out the Content attribute in DPWS servers: I agree that because the attribute is optional and has a default value of ".../Any" it is easy to profile out its use in DPWS clients, but it is not enough. Let's say a embedded device can only expose its service WSDLs as references, for memory footprint reasons. This device may be accessed by DPWS clients, but there are use cases (for instance communications between devices and enterprise applications) where the client will not be a DPWS one. Such a client may want to use the Content attribute in its GetMetadata requests, for convenience reasons. What are the options of the device (or in fact any service not able to expose its metadata in all possible formats) receiving a GetMetadataRequest with the Content attribute having an unsupported value: 1) Not return any value for the metadata: this is compliant with the spec, but not very helpful for the client. How does it know that the metadata is indeed available, but in a different format? Should it be coded as to retry with a different @Content value until it succeeds (which may never happen, if the metadata is indeed not available)? Should it look at the WS-Policy assertion (thus making it kind of mandatory, and also creating a bootstrap problem)? If many servers behave in this way, I think it will lead many clients not to use the Content attribute at all, thus defeating the purpose of its introduction since the Submission version. 2) Return a DPWS-specific fault: this has two drawbacks: (i) it is a bit drastic, as the complete request (possibly batching requests for several metadata dialects) will fail, while most of the request could be OK; (ii) it will not be understood by a non-DPWS client, while in fact only these non-DPWS clients will receive it (DPWS clients would know that they should not use the Content attribute). So in fact only option 1) makes sense in the current version of the spec. Adding a new response type (e.g. mex:AlternateContent) in case where the requested metadata is available in a different format would solve the problem in an elegant way: - It will not increase the complexity for clients not using the Content attribute (e.g. DPWS clients): this response type will never be returned when using the ".../Any" Content value, so these clients will not have to support it. - It will provide enough information for the client to retry the request in an efficient way: only metadata for which this return value has been provided will need to be requested again. Adding a @ContentHints as an attribute or subelements to the returned element would allow the client to use the appropriate content type (alternatively to keep things simple, it could use the ".../Any" value in the second request). Overall, because the Content attribute is a new feature that introduces some non-trivial additional complexity in services supporting WS-Mex (and this includes DPWS devices), I think it would be fair that the WG introduces an associated mechanism allowing its removal in a convenient way. I also think that this issue has a larger scope that DPWS only. I hope this explanation will allow the WG to reconsider its decision. Cheers Antoine Ram Jeyaraman a écrit : > > Hi Antoine, > > Thanks for submitting the issue. The WG discussed this and decided to > close this issue with no action. > > The compliance section of every specification states that an optional > element of a request MUST be able to be handled by a server, unless > the specification has specific text allowing it as a server option. > Hence, the service is required to support the Content attribute. > > The WG felt that since the specification currently states [1] that > when the Content attribute is not present it defaults to any content > type. This allows a client to NOT use the Content attribute that would > allow the service to send back the metadata in any content > type/format. Hence, there is no need for a fault for the service to > indicate it does not support a > > particular content type. Thus, a profile could remove the use of > Content attribute by a client allowing a service to return any content > type. > > Further, if the client wants a particular content type or format, it > can request that by specifying that in the GetMetadata request. > > Please let us know if you have any questions. > > Thank you. > > > [1] “When not present the default value is > "http://www.w3.org/2002/ws/ra/edcopies/ws-mex/Content/Any". > > ------------------------------------------------------------------------ > > > Ce message entrant est certifié sans virus connu. > Analyse effectuée par AVG - www.avg.fr > Version: 9.0.819 / Base de données virale: 271.1.1/2868 - Date: 05/11/10 20:40:00 > >
Received on Thursday, 13 May 2010 10:37:54 UTC