[kepler-dev] XMLToken and RecordToken

Wed Dec 8 13:05:03 PST 2004

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