[kepler-dev] XMLToken and RecordToken

[Jianting Zhang]

Thanks for the replies and I really appreciate. One thing I like 
Ptolemy/Kepler is its typing system which imposes syntactic/semantic 
constraints on the data flows and makes workflow more meaningful.

One more question regarding to typing in Ptolemy. I also noticed that some 
tokes have the corresponding types in TypeLattice, while some (such as 
ImageToken) does not. This may suggest that the token types appear in 
TypeLattice are basic (not necessarily in BaseType such as RecordType and 
ArrayType) while the rest are not. However, what's the criteria to decide 
what are "basic" and what are not? For example, although the XMLToken type 
appeared in TypeLattice, it is more like an constrained version of 
StringToken. Another example is the DBConnection token in Kepler (not in 
Ptolemy) which is basically a placeholder for a class instance of 
java.sql.Connection, but it has its own type (defined in BaseType).

I'm not a formal language person, but conceptually there should be a set of 
types in a type system  that are mutually independent and minimal. Although 
syntactic sugar might be needed for practical reasons, this set of types 
should be clear and well-defined. So my question again is what's the basic 
set of types in Ptolemy and what's the guideline to define/derive new 
types/tokes? I consulted Ptolemy documents and found only 1-2 pages (section 
3.4 of software design documentation) talked about this issue. Any further 
references are extremely welcome.

Thanks again

Jianting




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


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