[kepler-dev] XMLToken and RecordToken

Wed Dec 8 13:21:35 PST 2004

I recently spent quite a lot of efforts in Apache Axis and was trying to 
pass complex data types (including arrays and structures and their 
combinations) to Axis server through SOAP message. Basically this is the 
problem of mapping XML complex types to Java classes. What Axis does is that 
it requires a mapping registry as a configuration file at the server side. 
The problem is that the mapping is static and has to be exact and the QName 
thing complicated the mapping quite a lot. I think semantic registration 
might solve this problem to a certain extent.

Jianting

----- Original Message ----- 
From: "Bertram Ludaescher" <ludaesch at sdsc.edu>
To: "Jianting Zhang" <jzhang at lternet.edu>
Cc: "Edward A. Lee" <eal at eecs.berkeley.edu>; "Christopher Brooks" 
<cxh at eecs.berkeley.edu>; <ellen_zh at eecs.berkeley.edu>; 
<kepler-dev at ecoinformatics.org>
Sent: Wednesday, December 08, 2004 2:05 PM
Subject: Re: [kepler-dev] XMLToken and RecordToken

>>>>>> "JZ" == Jianting Zhang <jzhang at lternet.edu> writes:
> JZ>
> JZ> Thanks for the replies and I really appreciate. One thing I like
> JZ> Ptolemy/Kepler is its typing system which imposes syntactic/semantic
> JZ> constraints on the data flows and makes workflow more meaningful.
>
> Thanks for the flowers! Those would go to Ptolemy folks mostly for
> their sophisticated type system. In Kepler and supporting projects
> like SEEK and GEON we've spent some time thinking about "semantic
> types" -- a bit like the static unit type system that was recently
> added to Kepler, but not limited to units but general concept
> hierarchies and ontologies in general.
>
> One of the more elaborated features is an "registration mapping" that
> links between the data structure (or structural type) and the ontology
> (or semantic type). This is what Shawn is also working on.
>
> We hope to develop this further and eventually add this to
> Kepler/Ptolemy -- how exactly remains to be figured out.
>
> But expect some cool (and scientist-oriented!) stuff coming down the
> pike..
>
> JZ> One more question regarding to typing in Ptolemy. I also noticed that 
> some
> JZ> tokes have the corresponding types in TypeLattice, while some (such as
> JZ> ImageToken) does not. This may suggest that the token types appear in
> JZ> TypeLattice are basic (not necessarily in BaseType such as RecordType 
> and
> JZ> ArrayType) while the rest are not. However, what's the criteria to 
> decide
> JZ> what are "basic" and what are not? For example, although the XMLToken 
> type
> JZ> appeared in TypeLattice, it is more like an constrained version of
> JZ> StringToken. Another example is the DBConnection token in Kepler (not 
> in
> JZ> Ptolemy) which is basically a placeholder for a class instance of
> JZ> java.sql.Connection, but it has its own type (defined in BaseType).
> JZ>
> JZ> I'm not a formal language person, but conceptually there should be a 
> set of
> JZ> types in a type system  that are mutually independent and minimal. 
> Although
> JZ> syntactic sugar might be needed for practical reasons, this set of 
> types
> JZ> should be clear and well-defined. So my question again is what's the 
> basic
> JZ> set of types in Ptolemy and what's the guideline to define/derive new
> JZ> types/tokes? I consulted Ptolemy documents and found only 1-2 pages 
> (section
> JZ> 3.4 of software design documentation) talked about this issue. Any 
> further
> JZ> references are extremely welcome.
>
> I let the Ptolemy folks answer this for the Ptolemy type system.
>
> As for the "semantic types", notions such as minimality and mutual
> independence are not as critical (or  even desirable) as compared with
> the traditional "programming language types"...
>
> this is a topic for a longer discussion...
>
> Bertram
>
> JZ>
> JZ> Thanks again
> JZ>
> JZ> Jianting
> JZ>
> JZ>
> JZ>
> JZ>
> JZ> ----- Original Message ----- 
> JZ> From: "Edward A. Lee" <eal at eecs.berkeley.edu>
> JZ> To: "Christopher Brooks" <cxh at eecs.berkeley.edu>
> JZ> Cc: "Jianting Zhang" <jzhang at lternet.edu>; "Edward A. Lee"
> JZ> <eal at eecs.berkeley.edu>; <ellen_zh at eecs.berkeley.edu>;
> JZ> <kepler-dev at ecoinformatics.org>
> JZ> Sent: Wednesday, December 08, 2004 11:50 AM
> JZ> Subject: Re: [kepler-dev] XMLToken and RecordToken
> JZ>
> JZ>
>>>
>>> Actually, I think RecordToken will provide type safety.
>>> In fact, it may be too much type safety, since you could in fact
>>> use the type system to constrain the structure of an XML document...
>>>
>>> I agree that a well-thought-through XMLToken, well integrated
>>> with the type system, would be the best solution.
>>>
>>> Edward
>>>
>>> At 09:37 AM 12/8/2004 -0800, Christopher Brooks wrote:
>>>> XMLToken was implemented by Yang Zhao, cc'd here.  She might
>>>> be able to elaborate on the design philosophy.
>>>>
>>>> XMLToken is used in actor/lib/xslt/XSLTransformer.java
>>>> and actor/lib/conversions/StringToXML.java
>>>>
>>>> The advantage of using XMLToken over using a more generic token is
>>>> that when the generic token is extended, we get type safety and we can
>>>> have more specific parsing and processing in the extended token (in
>>>> this case, XMLToken).
>>>> Often, we end up developing code that uses a fairly generic token such
>>>> as ObjectToken or RecordToken and then later creating a specialized
>>>> token that has special operations.
>>>>
>>>> I don't have a strong opinion, but probably the best thing to do would
>>>> be to add functionality to XMToken over using RecordToken so as to
>>>> have type safety.  However, I might be unclear on your plans, when
>>>> you say "extend XMLToken", I'm not sure if you mean adding
>>>> functionality to XMLToken or subclassing XMLToken.
>>>>
>>>> _Christopher
>>>>
>>>> --------
>>>>
>>>> Dear Dr. Lee:
>>>>
>>>> My name is Jianting Zhang and I'm doing my post-doc with SEEK project
>>>> at
>>>> UNM. My background is in database and I'm learning Ptlemey/Kepler.
>>>>
>>>> I noticed that there are XMLToken and RecordToken in Ptolemy. While I
>>>> understand the funtion of RecordType, it seems to me that XMLToken is
>>>> currently just a placeholder with little real functionality. Could
>>>> you
>>>> elabarate a little bit about the design philosophy of XMLToken?
>>>>
>>>> I'm working on workflow of geospatial data processing in Kepler which
>>>> involves many interfacing issues with crrent GIS/Remote Sensing
>>>> processing
>>>> software, which in turn invovles user defined complex data types.
>>>> Also I'm
>>>> interested in making the processing distributed by using
>>>> dynamic(stubless)
>>>> Web services. At present, it seems that XML/GML is a good solution to
>>>> link
>>>> GIS/RS-Web Services-Ptolemy/Kepler. This is the reason I'm intestered
>>>> in
>>>> XMLToken in Ptolemy.
>>>>
>>>> Since I didn't find desired functionality (accessing name/type/value
>>>> pair i
>>>> n
>>>> an XML string and type checking) in XMLToken, I'm thinking maping DOM
>>>> hierchary to RecordType hierarchy, which is possible at least
>>>> conceptually.
>>>>
>>>> Alternatively, I can extend XMLToken. Would you comment which way
>>>> might be
>>>> better?
>>>>
>>>> Best Regards
>>>>
>>>> Jianting
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> kepler-dev mailing list
>>>> kepler-dev at ecoinformatics.org
>>>> http://www.ecoinformatics.org/mailman/listinfo/kepler-dev
>>>> --------
>>>
>>> ------------
>>> Edward A. Lee, Professor
>>> 518 Cory Hall, UC Berkeley, Berkeley, CA 94720
>>> phone: 510-642-0455, fax: 510-642-2718
>>> 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
>>>
> JZ>
> JZ> _______________________________________________
> JZ> kepler-dev mailing list
> JZ> kepler-dev at ecoinformatics.org
> JZ> http://www.ecoinformatics.org/mailman/listinfo/kepler-dev
> 