Re: [unitsml] WSDL Example for Discussion

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

Quoting "Stuart Chalk" <schalk@unf.edu>:

> As we talked about yesterday please find below information regarding  
>  an example WSDL service that I have put up.
>
> The service converts temperature and requires a value and a unit as   
> input parameters.  The URL of the WSDL is
> http://chalk.coas.unf.edu:8080/axis2/services/tempConvert?wsdl
> (...)
> You can play around with the other methods getCelcius and  
> getFarenheit  and units F and K
>
> Attached is an example file with the unitsML WSDLConversionFrom   
> element referencing the WSDL above.
> (Bob the code references a slightly diferent version of the   
> SimpleSchema I put up)
>
> Personally, I think the initialUnit is not required because the   
> pointer is to the generic conversion
> service not to a method that requires a unit of kelvin as default.
>
> Thoughts?

I don't think we have (anywhere near) enough information in the  
WSDLConversionFrom element. Which endpoint to use, what to put in  
which parameters, where to put the numerical value of the unit, is  
lacking.

I was playing around a bit with it:

import edu.unf.coas.chalk.tempconvert.*;

public class Client {
         public static void main(String[] args) {
                 TempConvert tc = new TempConvert();
                 System.out.print(args[0] + " " + args[1] + " = ");
                 TempConvertPortType port = tc.getTempConvertSOAP12PortHttp();
                 try {
                         String res = port.getKelvin(args[0], args[1]);
                         System.out.print(res + ", ");
                         res = port.getFahrenheit(args[0], args[1]);
                         System.out.print(res + ", ");
                         res = port.getCelcius(args[0], args[1]);
                         System.out.println(res);
                 } catch (Exception ex) {
                         System.out.println("EX : " + ex);
                         ex.printStackTrace(System.out);
                 }
         }
}

(the content of the edu.unf.coas.chalk.tempconvert package were  
generated by wsimport -keep -extension on a locally edited copy of the  
WSDL as wsimport doesn't like the xs:any reference)

Here are some observations (not unitsml related)
- The WSDL seems broken? (try to run java's wsimport on it)
- 10C =  283 K, 50 ?F, 10 ?C
- 10.0 = <value unit="K">283.2</value>, 50.0 ?F, 10.0 ?C <-- wondering  
what's happening here..


design of the process: You noticed that the initialUnit is  
superfluous. It only is because you give the current unit explicitly  
(i.e. the part of unit=C above). From the document point of view the  
value of having initialUnit in is better than having it only as  
(encoded, hidden, documented or whatever) argument to the (http or  
soap) invocation of one of the methods. You say it's a generic  
service, that's true, on the other hand the more generic the services  
are the harder it becomes to encode that in unitsml. Values that we  
can expect any unitsml processor to have available are the desired and  
the current unit, as well as the numerical value(s). We need to  
communicate how to encode these (e.g. in xml transport, element or  
attribute? name of the thing?). We need to communicate where to put  
them. In the http transport case e.g. we'd need to provide a sample  
template. The less we specify, the more the processor has to calculate  
on its own and the less likely it becomes that unitsml processors  
other than the ones we write will support all the necessary cases to  
deduce arguments as general as possible. So I'd say, we specify more.  
Atm after all we only have: "Here is a file telling you how to reach  
and where to find N functions". We EXPECT these functions to be units  
and conversion related. But we don't have a naming convention for the  
methods. If in the file there are two functions f(x,y) and g(a,b,c)  
we'd neither know (programmatically) what x and y (or a, b and c  
respectively) mean, or which of the two methods to call. So, we might  
also suggest naming conventions on parameters and methods so that we  
can spare the information from the document. But we need that  
information...

In that light, of course the most accessible services only take one  
parameter (the numerical value), encode from and to units in their  
name and have e.g. the hint "convert" embedded. They should use (e.g.)  
"value" as name of the numerical value parameter. It should be obvious  
what to do with convertCelsiusKelvin(value):  
http...../convertCelsiusKelvin?value=x

Of course (from a CS POV) this is ugly. Then again the code for the  
stuff mentioned in previous paragraph could easily written by a  
program referring to a DB of existing conversions, calling a generic  
function, but I digress...

I just talked to Bob about the necessary information in the instance  
document as well as in the guidelines. I'll try to outline the things  
that I think should be in the document, in the guidelines, and thus  
what we require the processor to be able to do (i.e. sketch out above  
thoughts to concrete suggestions). I'll continue on that later.

-Martin