Re: WS-RA issue 9700 disposition

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:53 UTC