WSDL 2/2 1st attempt...

["Martin S. Weber" <martin.weber@nist.gov>]

Hey TC..

(this mail shall be recorded as part of the 2-week asynchronous portion of
the UnitsML OASIS TC Meeting of Feb 11 2009)

So, this is the long answer. Don't blame me for it, the topic just demands
some more attention than meets the eye on first glance.

Here's the challenges of trying to enable a UnitsML processor to talk to a
WSDL described web service out there (or at least those I could think of):

- There are different versions of the WSDL out there in use. The different
versions partially define quite different ways to describe a webservice. E.g.
the ports used in 1.x vs. the endpoints/interfaces in 2.0. Talking to both
1.x and 2.x WSDL described services requires a different set of attributes.

- In a WSDL file, can have multiple services, endpoints, operations,
interfaces, protocols, transports, locations, ... There either needs to be
a standard naming rule so that a machine processor can pick the correct
choice, or an attribute per choice so that one can store which to pick.
Multiply by ~2 (as of the above).

- In the case of the non-trivial endpoint of communication on the webservice
side (i.e. anything non-HTTP-GET), the correct construction of the messages
might be quite hard. A UnitsML processor needs to be aware of the vocabulary
(both syntactic and semantic wise) used to construct the message(s). Yet the
only vocabulary a UnitsML processor needs to know about is UnitsML itself.
Then again, transporting a numeric value is outside the scope of the UnitsML
but clearly needed for interoperating with a converting webservice.

- Even in the case of the trivial endpoint of communication (i.e. a HTTP GET
with known parameters and/or a URL template to use) we do not have means of
communicating the 'from' unit unambigiously (that's the reason we're working
on UnitsML after all -- lack of unambigious markup for units).

- The Webservice need not implement direct conversion from one unit to another
by computation; it might as well return a Float64ConversionFrom element to
be used instead. Or a MathML-marked up formula to use. Or x86 object code to
be dynamically linked into the running process. Or ...

- The message construction / extraction / flow makes the UnitsML processor
more heavyweight and complex, thus more unlikely to be done (in its entirety).
Also the "trivial" unitsml processor (a set of XSLT stylesheets with only
requiring an XSLT runtime) is unlikely to be able to cover all the above,
bringing in the need for more powerful/bloated less portable runtimes (like,
e.g., the JVM or the .NET runtime).

- probably several more I cannot see anylonger due to having blinders on.

So how to meet these challenges? In my opinion adding _all_ the necessary
information for meeting all of the above will result in a baroque
WSDLConversionFrom element which will about never get correctly and fully
filled out, except by a processor itself, and this can't be the idea behind
it. So instead, I suppose we could come up with different levels of WSDL
support from within UnitsML. I'm thinking of several (~3) levels here, ranging
from a very narrow restrictions on the webservice up to hammering lots of
intelligence into the UnitsML processor. What these levels of support have
in common is a different set of pre-requisites on the web-service. These
would be stated as part of the UnitsML Guidelines. Additionally there should
be a way to validate your web-service against the UnitsML requirements
(like, you upload your WSDL to some web-service and it tells you you're
conforming to this and that level, because ...)

Level 1: Making life easy for dumb UnitsML processors. Excessive NDRs for
the webservices, including at least:
- WSDL conforms to specific WSDL specification version [suggesting 2.0 here]
- Disallow SOAP
- Only allow use of HTTP GET (1)
- Only one service, binding, interface, operation in the file.
- service must convert between numerical values and deliver result
- service name follows naming convention, e.g. convertFrom<Unit>To<Unit>
- parameter name follows naming convention, e.g. "value"
- (there must only exist one parameter, the numerical value)
- Use only one fault message which is defined in the Guidelines and not
   defined in the WSDL (but merely referenced from there)
- Reply contains the "naked" value only (or in an XML message that is
   defined in the UnitsML Guidelines).
- Reply fits into defined data type (e.g. 'double')

=> The goal of "level 1" is to allow an unitsml processor made up by nothing
more than XSLT support (yeah with XPath obviously and the ability to fetch
data from foreign URLS but that's included in full XSLT support), with a
minimum of choices the processor has to make. The necessary storage in the
UnitsML file then is the initialUnit-URL and the URL of the WSDL.

Level 2: Making life easier for the webservice author(s) while still not
making life too hard for the UnitsML processors.
- WSDL 2.0 conformant.
- suggest use of HTTP GET (1)
- multiple services, bindings, interfaces, operations allowed in the file
- services should convert between numerical values and deliver result
- Conversion services (as above) follow naming convention, e.g. contain
   the substring "convert" somewhere
- fixed parameter name for the current numerical value in the potential
   message templates. If units need to be communicated, also fixed parameter
   name for that (so processor has an easier time inserting into the correct
   places in the template).
- If units are to be communicated, use UnitsML for this.
- reply contains value in a way that is Xpath-extractable

=> The goal of "level 2" is to still allow an unitsml processor made up by
nothing but XSLT (although admittedly doing that will be a considerable pain).
Such an UnitsML processor need not resort to heuristics to interoperate with
the webservice(s). It needs considerable more information though, as was
outlined in my previous email message.

Level 3: Valuing the Web-service author. Ignoring the PITA of the UnitsML
processor author.
- Have fun web-service authors. Do whatever you want.

=> I honestly do not see someone writing a unitsml processor that will support
web-services without constraints at this level, although with some AI it might
well be possible, maybe even in XSLT (although personally I doubt its
practicality).  Also the so-far suggested attributes on the WSDLConversionFrom
element will unlikely be enough (but might be, depending on the quality of
the heuristics).


.. so enough babble on my side. What do you think?

-Martin

(1) We should suggest usage of HTTP GET for such conversion services anyways,
as by W3C TAG finding "URIs, Addressability and the use of HTTP GET and POST"
at http://www.w3.org/2001/tag/doc/whenToUseGet