[kepler-dev] web service actor

Shawn Bowers bowers at sdsc.edu
Fri Feb 27 09:37:22 PST 2004


On Fri, 27 Feb 2004, Bertram Ludaescher wrote:

> (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...

I don't think I understand your point here.  By "named" types what do you 
mean? It seems to me that you either have some "semantic" agreement or you 
don't. If you don't, then how can structural types help. If there is 
implied semantic agreement, then that is just an implementation of 
semantic types, right? Maybe you can explain this offline to me, or if 
you think it is of general interest we can keep the thread going ... 

Also, I think this somewhat may relate to Edward's previous email about 
subtyping and XML Schema.  The real problem is this notion of people 
agreeing on "semantic information." The actor example assumes that the 
"extended" schema builds upon the original -- that is semantic agreement, 
and the two schemas weren't developed in isolation. This is a perfectly 
fine example of subtyping for XML, however, and XML schema even offers 
ways to do this, for example, by allowing optional items and unconstrained 
content (which is done in key places within EML, e.g.).  But, I think 
these kind of subtyping situations are rare in the broader 
XML/DB community, and so isn't necesarrily mainstream. 

> 
> 
> 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...

Just a quick comment: I think there is a danger to allow out-right
arbitrary Java classes as valid types without requiring them to be wrapped
into real structural types (whether in XML Schema or as Ptolemy types).  
The problem is that (1) no one can use the service unless they have access
to the class (a big problem for reusability in SEEK and de-coupling in
general) and how it is serialized/de-serialized (a language/package
issue), (2) the class must be loaded (dynamically or statically)  into the
classloader (causing severe limitations for "generic"  actors such as
Ilkay's web-service actor), and (3) it potentially breaks static type
checking in Ptolemy, unless the class can be placed within the Ptolemy
type lattice.  There may be other problems as well that I am not aware of.

Another approach would be to just treat these serialized objects as 
binary string data (that is their type, e.g.)  -- and to use the service, 
you must understand the binary format.

Shawn

> 
> 
> 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
> 




More information about the Kepler-dev mailing list