From marku@spot.cs.waikato.ac.nz Thu Sep 5 11:08:07 2002 Date: Wed, 14 Aug 2002 13:00:34 +1200 From: Mark Utting To: czt-project@comlab.ox.ac.uk Subject: CZT: draft Java class APIs Dear Fellow CZT'ers, You may remember that Nicholas Daley (a 5th-year student) and I were translating Ian Toyn's XML proposal into Java classes. Nicholas has now produced a draft version of the Java classes (plus Reader and Writer plugins for Zeta for XML <--> Java translation). The documentation of these Java syntax tree classes is available for your comments here: http://www.cs.waikato.ac.nz/~marku/czt/overview-tree.html We have done quite a direct translation from the XML (except that we used subclasses for the different kinds of quantifiers and logical predicates, rather than tagging them with an attribute -- this seems more object-oriented and convenient in Java). However, the result is often rather bigger and more complex than we like. Hence, we have several proposals to simplify the XML and the Java classes: 1. The DTD should use namespace rather than Z-prefix+Z-colon? (Nicholas assures me that this would simplify the programming interface to the DOM XML classes, and achieve the same effect). 2. Why have so many unparsed alternatives? They must be reflected in the Java AST trees, so are always visible to the programmer, which is a pain. (I imagine that very few tools will generate mixes of parsed and unparsed Z). Allowing every element of the DTD to have an unparsed alternative triples the number of Java classes and means that the programmer who is traversing a AST tree must be constantly checking that each component of the current node is correctly parsed. A better alternative might be to only add an unparsed alternative to each element that is already a choice. That is: Z-Para, Z-Pred, Z-Expr, Z-Decl and perhaps Z-Type These are the major chunks of the language anyway, so the effect of doing this would be to simplify the DTD (and the Java AST), at the cost of having slightly larger 'unparsed' chunks. For example, if a paragraph contained several mutually recursive freetypes, and one of them could not be parsed, you would have to make the whole freetype paragraph unparsed in the XML file, rather than just one of the freetypes. What do you think about this simplification? 3. Should annotations be more flexible (and less context dependent)? Currently, the XML DTD allows only one annotation per construct, but that annotation can be overridden to contain multiple kinds of information. It is only possible to attach ALL these annotations, or NONE of them. This means that two different packages cannot both add their own (independent) annotations. An alternative would be for each entity to allow (Z-Annotation)*, so that SEVERAL annotations can be attached. Some convention would be needed about the meaning of having multiple annotations of the same kind (eg. several type annotations). Perhaps this should be an error, or the most recently added one takes precedence. A related issue is how strongly 'typed' (or 'context dependent') the annotations should be. For example, currently we can define a completely different set of annotations for the 'true' predicate than the 'false' predicate. This seems overkill. With this system, to add a new annotation to all kinds of predicates, one must override about 7 different elements, while to add an expression annotation, one must override 23 elements. A simpler design would be for each kind of term to conceptually have a linked list of 'Annotation' objects. Then it is easy to define several subclasses of 'Annotation', and attach them to any kind of Term without restriction. Result: more flexible, but less strongly typed. Comments? (I'm not sure I've explained this last one clearly enough...) Mark. Dr Mark Utting, Senior Lecturer, Dept. of Computer Science, The University of Waikato, Private Bag 3105, Hamilton, New Zealand. Phone: +64 7 838 4791 Web: http://www.cs.waikato.ac.nz/~marku Fax: +64 7 858 5095 Email: marku@cs.waikato.ac.nz ----------------------------------------------------------------------- This message is sent to the czt-project mailing list. To join, send an email to czt-project-request@comlab.ox.ac.uk containing the single line subscribe To unsubscribe, do the same, changing the message appropriately. To send a message to the list, write to czt-project@comlab.ox.ac.uk. The CZT home page is at: http://web.comlab.ox.ac.uk/oucl/work/andrew.martin/CZT/ -----------------------------------------------------------------------