WSDL 1/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)

(excuse the lengthy message, trying to make my thoughts "behind" clear)

So after overcoming various obstacles, like e.g. lack of health, here are my
thoughts on the WSDL issue. This is a twofold message, first of all I have
some ideas about what we want to achieve with storing a WSDL conversion, and
second, given these premises, that's what I suppose we should have to achieve
these.

1) Stuart asked, what is it we want to achieve with the inclusion of the WSDL
reference for UnitsML?

Well, to me the answer is: Give non-human UnitsML processors additional
capabilities to convert between units. ("additional" being transitive here)

Why "non-human"?

Given that WSDL is a quite verbose vocabulary to describe something like "go
to this URL, add a '&value=<your number here>' and you'll get the new value
of the unit you're looking for", I don't think we want to encourage people
to use it to refer to a webservice for humans. If we want the above, a comment
somewhere is enough, or a SpecialConversionFrom that includes the above quote
will be just fine. If we are referencing a WSDL though, I figure we do that
so that we can get it, look at it, and take the next steps of action based
on the content of the WSDL. Only the non-adept in WSDL will quickly be able
to determine, e.g., if there's a HTTP transport available and the message
exchange pattern and style described ends up being a HTTP GET, so that (s)he
just can construct an URL and invoke the service this way. So I see it as
given that referencing a WSDL is for the sole purpose of machine support.

As a justification for the services existence that means, either we have
additional capabilities in the web service (e.g. it returns MathML,
YourFavouriteML, unlimited precision integers/floats/42s) or we are  
referencing
a centralized service repository for the sake of not having to embed all
these conversion factors in the UnitsML data. Also I can figure someone might
want to use it for conversion factors that are not fixed per se (e.g. for
currency conversion(+), you want to get the latest exchange rate. Or maybe
there's an experimental series ongoing on how to convert a "sixpack" (standard
item coming up in the TC) to "permille of blood alcohol", or ...).

Using the WSDL Conversion in some way thus enables users of the unitsml to
model "more" than could be done by the linear equation, thus making the
content of a unitsml data chunk more expressive. On the other hand, there's
less immediate information available. Even the most stupid XSLT "processor"
is able to convert between units (I have one here) using the information
stored in the Float64ConversionFrom. For analyzing a WSDL, communicating with
the service (also constructing the correct messages back and forth in the
correct protocol, recognizing faults, ...) a more sophisticated processor is
required, if we do not encourage a certain discipline (in the documentation
of the WSDL Conversion element and children and/or in the UnitsML guidelines).
Additionally, the processor might even be crippled by relying on a webservice
to do conversions. Imagine a display for sensor networks behind some corporate
firewall and/or without access to the internet at all, trying to convert by
using a service on a machine "out there". That's why for me, usage of a web-
service can only be an enhancement to existing, documented conversion factors.

For the second question, this will be in a separate mail. I was caught by
surprise seeing how a juicy topic this is.

-Martin

(+) at the awareness that UnitsML is not for encoding currency, but let's
ignore that for the sake of a fitting example