new UWS 1.1 WD

[Paul Harrison]

On 2014-10 -01, at 10:50, Grégory Mantelet <gmantele at ari.uni-heidelberg.de> wrote:
> 
>> I think that they could be added to 1.1 - the only downside would be that requires a schema change officially and we come back to that tricky question of how strict old clients (and new ones) are about XML validation - if only we had not used XML schema define the XML structures and had an “ignore what you don’t understand” general rule in place it would be much easier to evolve these standards.
> 
> Yes, that's true. It would be interesting to see how many UWS clients expect a strict XML document. For instance, I think that the TAP interface (for asynchronous requests) of TOPCAT does not.
> 
>> Paul.
>> 
>> p.s. I think that your b.bis is a step too far to include in the UWS standard!
> 
> Yes, I agree...that's why I put it in bis and inside parenthesis. But my goal was just to keep that use case in mind while modifying the 'result' item....particularly if a possibility of an open XML structure allows additionnal custom attributes for the 'result' item. I think that allowing more attributes could be a good idea: first, because it allows a 'rows' attribute in the context of TAP, and then, because it does not block old clients on a too strict XML schema (which is now our "problem" for 'mime' and 'size' attributes).

we could add 

      <xs:anyAttribute namespace="urn:uwsextension" processContents="lax" />


to the schema ResultReference definition, which would allow any attribute in the result element as long as it used the urn:uwsextension namespace (or we could be even more lax and allow any namespace - but the use of the namespace could signal that the attribute had been added "on purpose”).

I think that as long as the UWS 1.1 schema does not invalidate any original UWS 1.0 XML instances then we can get away with the upgrade. Again the only question is what 1.0 clients would do when they encountered instances with 1.1 namespaces - I can see several possible scenarios

1. they are looking at the namespace to identify the content and throw it out because the namespace does not match the one they expect.
2. they use an XML validator library that is actually capable  of picking up the 1.1 schema as long as the instance has the proper header, and because validation is still ok they proceed.
3. they did parsing without actual schema validation and either;
     a) just ignore the extra things that they do not understand
     b) signal an error because there are extra attributes.

On balance I think that more clients are likely to be able to handle this than not.

Paul