From sunjing@comp.nus.edu.sg Thu Sep 5 11:08:19 2002 Date: Thu, 15 Aug 2002 20:38:40 +0800 (GMT-8) From: Sun Jing To: Mark Utting Cc: czt-project@comlab.ox.ac.uk Subject: Re: CZT: draft Java class APIs Hi, We have constructed an XML Schema definition for the Z specification language and it's extensions (Object-Z/TCOZ), available at: http://nt-appn.comp.nus.edu.sg/fm/zml/z-stand/zml-xsd.htm Any comments on this are very welcome. A Z/Object-Z/TCOZ type checker prototype and an auto-translator to UML class and statechart diagrams (through XMI) were built based on this XML schema definition. Here is a forthcoming paper: J. S. Dong, Y. F. Li, J. Sun, J. Sun and H. Wang. XML-based static type checking and dynamic visualization for TCOZ. ICFEM'02. LNCS, Oct 2002. We can send you a copy if you are interested in this. Best regards. Jing Sun On Wed, 14 Aug 2002, Mark Utting wrote: > 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/ > ----------------------------------------------------------------------- > ----------------------------------------------------------------------- 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/ -----------------------------------------------------------------------