Re: WS-RA issue 9700 disposition

Antoine wrote on 05/13/2010 06:37:20 AM:
> 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.

You're correct that a service _will not_ be able to profile out the
Content attribute.  The WG discussed this and it was felt that allowing
a service to not support the Content attribute would revert the spec back 
to its
old state which wasn't optimal.  The notion of a service never being 
required to return the data in a format that the client would find useful
is not a situation that we wanted to return to.  Remember that w/o the
Content attribute the service is not required to return any particular
format - even if it does have it.  And of course a possible answer to
this is to just require the service to return all types it has, however
if client isn't interested in a large amount of data (or in other format
types) then it might be stuck.

> 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.

Yes and since its a required feature, all MEX services that support
GetMetadata MUST support the Content attribute.  They may not support all
Content forms for all data types, but they MUST understand the attribute.
This can not be profiled out.

The WG discussed some other points too:
- if the client could live with more than one form then it could ask for
  each one on the GetMetadata request - or just specify "All"
- it seems that the one form that people might want to avoid is the
  inlined one, so the overhead of people simply asking for the EPR
  and URL forms seemed minimal.

> 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)? 

Right - if it can indeed live with other Content forms then it can 
(should?)
include those in the request - or specify "All".

> Should it look at the WS-Policy assertion (thus making it kind of 
> mandatory, and also creating a bootstrap problem)? 

Ideally yes.  :-)  that's why its there.  If people choose not to use the
recommended advertising approach there isn't much we can do.

> 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.

Actually, I think what will happen is that people will just use "All" - 
which
is why its there.
 
> 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).

Agreed - we didn't like #2 either.

> 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).

True, but there were a couple of concerns with this that the WG discussed:
- this is, in essence, creating another advertising mechanism.  Having 
both
policy and this seemed redundant.
- while this seems like a nice benefit for those clients that will want to
issue a secondary request, it creates a bit of noise for those clients 
that
do not want this information.  Akin to "why are you telling me you have
oranges when I asked for apples?"

> 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.

-Doug