[kepler-dev] web service actor

Fri Feb 27 14:08:05 PST 2004

This seems like a good time for me to chime in..

I realized the other day that the type inference infrastructure in Ptolemy 
II currently
requires that the type of a value is derivable from the value...  (or, put 
another way,
the type system computes an abstract interpretation of a model)

However, it seems to me that although semantic types can be expressed in a
similar way, semantic types are rarely derivable from values.  I may assert 
semantic types
on an output port and an input port and require that they be consistent, 
but those
semantic types are not present (or really meaningful) at run time.  The 
semantic type
constraints of an actor cannot (generally) be derived from the function 
that an
actor computes.

Steve

At 06:35 AM 2/27/2004 -0800, Bertram Ludaescher wrote:

>Dear all:
>
>Here some of my own musings on the same topic:
>
>(1) First, here is a good paper for our XML typing discussions:
>http://homepages.inf.ed.ac.uk/wadler/papers/xml-essence/xml-essence.pdf
>I'd like to suggest it as required reading, as it deals with
>validating XML *objects* (or "documents", "fragments") wrt. XML Schema
>type. It also has some sobering statements such as this one:
>
>"So the essence of XML is this: the problem it solves is not hard, and
>it does not solve the problem well."
>
>But we knew that one already, right ;-)
>
>(2) The following is written from a databases point of view:
>http://www.acm.org/sigmod/record/issues/0203/dansuciu-lipkin.pdf
>It's a good introduction to the problem of typechecking *queries*.
>
>I think our problem, XML types for Kepler, has aspects of both
>(1), which deals with the problem from a programming languages POV and
>(2), which deals with the problem from a database POV.
>
>(3) We want to make sure that an XML token that "shows up" at a port
>of an actor corresponds to the (XML Schema) type of that port. That's
>(1).  At the same time, consider the problem of an actor which
>implements a database transformation, say specified in XQuery or in
>XSLT. Can we determine from the type at the input port(s) and the
>knowledge of the XML transformation, the type at the output port. This
>is the problem discussed in (2). While we're at it, we can apply the
>same schema reasoning to a whole (process) network.
>
>(4) We can call the XML Schema type of a port, its *structural type*.
>If we associate a port with a concept expression (say from an OWL
>ontology), then we can call this its *semantic type*. The question now
>is: if a connection between two actors is semantically type correct
>(here subtyping is defined as concept subsumption), but not
>structurally, can we infer a structural transformation that "does the
>trick", based on a "semantic registration" of the structural types.
>Uff... just read this (quite preliminary) work by Shawn and myself:
>http://www.sdsc.edu/~ludaesch/Paper/dils04.pdf
>
>(5) Another interesting question is this one: Can we solve the problem
>of semantic typing of ports by resorting to structural types. More
>specifically we used named types over a type system such as
>Hindley-Milner, possibly extended in various ways.
>I just came across this interesting work here: "Sexy Types in action"
>http://www.eecs.harvard.edu/~ccshan/cs252/usage.pdf
>Maybe it can help us with some answers...
>
>
>So coming back to Chad's original request, i.e., how about Java
>object types (since SOAP allows it) for actor ports: yep, why not.
>At the same time, we can take the opportunity to look at semantic
>types issues as well (Shawn will have a natural interest in that ;-)
>and solve the whole thing once and for all...
>
>
>Bertram
>
>
>
>
> >>>>> "EAL" == Edward A Lee <eal at eecs.berkeley.edu> writes:
>EAL>
>EAL> At 12:39 PM 2/26/2004 -0800, Shawn Bowers wrote:
> >> However, the classic notion of subtyping in programming languages doesn't
> >> otherwise pop up much for XML.  One reason is that XML is inherently
> >> "distributed."  Gven two schemas from different organizations, just
> >> because they have the same structure, or one is a subtype in terms of
> >> structure, there is absolutely no guarantee that these schemas have
> >> anything to do with each other.  The same is true if we also consider tag
> >> names (it may just be coincidence that some of the tag names are the
> >> same).  Because the schemas were developed independently, it would 
> also be
> >> pretty unusual that even for otherwise identical schemas, that the tag
> >> names or structure *would* be the same.
>EAL>
>EAL> Yes, good point...
>EAL>
>EAL> However, there might be real potential for subtyping.
>EAL> Consider for example an XML schema that represents actors
>EAL> and their interconnection (to pick a random example :-)
>EAL> and another that extends this with visual annotations (where
>EAL> on the screen an actor should be rendered, for example).
>EAL> A tool that used the former type would be unaffected by
>EAL> the addition of the latter data. In the current state of
>EAL> affairs, I think that such a tool (if it validates the XML)
>EAL> would have to reject a model with visual annotations, no?
>EAL>
>EAL> Edward
>EAL>
>EAL>
>EAL>
>EAL> ------------
>EAL> Edward A. Lee, Professor
>EAL> 518 Cory Hall, UC Berkeley, Berkeley, CA 94720
>EAL> phone: 510-642-0455, fax: 510-642-2739
>EAL> eal at eecs.Berkeley.EDU, http://ptolemy.eecs.berkeley.edu/~eal
>_______________________________________________
>kepler-dev mailing list
>kepler-dev at ecoinformatics.org
>http://www.ecoinformatics.org/mailman/listinfo/kepler-dev