[kepler-dev] XMLToken and RecordToken

[Edward A. Lee]

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