[kepler-dev] web service actor

Bertram Ludaescher ludaesch at sdsc.edu
Fri Feb 27 06:35:28 PST 2004


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



More information about the Kepler-dev mailing list