1 / 11

Designing an XML-based Exchange Format for Harmonia

Designing an XML-based Exchange Format for Harmonia. Marat Boshernitsan Susan L. Graham University of California, Berkeley, USA Exchange Formats Workshop WCRE 2000, Brisbane, Australia. Application Domain. Harmonia: a framework for constructing interactive language-based programming tools

tal
Download Presentation

Designing an XML-based Exchange Format for Harmonia

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Designing an XML-basedExchange Format for Harmonia Marat Boshernitsan Susan L. Graham University of California, Berkeley, USA Exchange Formats Workshop WCRE 2000, Brisbane, Australia

  2. Application Domain • Harmonia: a framework for constructing interactive language-based programming tools • Primary focus: front-end, user-visible tools (language-sensitive editors, source browsers, design assistants) • Simultaneously support many languages: C++, Java, as well as smaller domain-specific languages (make, bison, …) • Fine-grain version history: enables incremental analyses and other user services • Rapid prototyping: bindings for C++, C, Tcl, Java, Lisp • External tool integration: existing analyzers, source transformers, etc.

  3. use XML model internal program representation Exchange Format Requirements • General requirements • Support for industry standards • Convenient APIs • Easy to generate, store, and parse • Domain requirements • Small tools (individual source files) and large tools (entire software projects) • Harmonia-enabled tools as well as external language-sensitive tools • Legacy text-based tools (editors, compilers, etc.) • Support many languages – can not standardize on one encoding, e.g. JavaML

  4. actually, ASG! to variable declaration to method declaration Example • Text: “if (cond) f();” • AST… IfThenStmt if ( VarRef ) ExprStmt Name MethodCall ; cond Name ( Args ) f

  5. IfThenStmt if ( VarRef ) ExprStmt Name MethodCall1 ; cond Name2 (4 Args5 )6 f3 to method declaration: 42 Encoding Graphs <node id=1 name=MethodCall> <edge target=2 type=child/> <edge target=4 type=child/> <edge target=5 type=child/> <edge target=6 type=child/> </node> <node id=2 name=Name> <edge target=3 type=child/> <edge target=42 type=decl/> </node> <node id=3 name=IDENT text="f"/> <node id=4 name=LPAREN text="("/> <node id=5 name=Args></node> <node id=6 name=RPAREN text=")"/>

  6. Encoding Trees <node id=1 name=MethodCall> <edge target=2 type=child/> <edge target=4 type=child/> <edge target=5 type=child/> <edge target=6 type=child/> </node> <node id=2 name=Name> <edge target=3 type=child/> <edge target=42 type=decl/> </node> <node id=3 name=IDENT text="f"/> <node id=4 name=LPAREN text="("/> <node id=5 name=Args></node> <node id=6 name=RPAREN text=")"/> IfThenStmt if ( VarRef ) ExprStmt Name MethodCall1 ; cond Name2 (4 Args5 )6 f3 to method declaration:42 <node id=1 name=MethodCall> <node id=2 name=Name decl=42> <node id=3 name=IDENT text="f"/> </node> <node id=4 name=LPAREN text="("/> <node id=5 name=Args></node> <node id=6 name=RPAREN text=")"/> </node>

  7. Schemas • XML documents should have a DTD <node id=1 name=MethodCall> <node id=2 name=Name decl=42> <node id=3 name=IDENT text="f"/> </node> <node id=4 name=LPAREN text="("/> <node id=5 name=Args></node> <node id=6 name=RPAREN text=")"/> </node> <!ELEMENT node (node)*> <!ATTLIST node ...all node attributes...> • No type restrictions – cannot validate with respect to programming language • Need additional data schema

  8. Schemas (cont.) • Idea: use the same typing mechanism as the AST • AST nodes typed according to the abstract grammar • Generate DTD from abstract grammar (used by the parser) • Interpret the DTD as a data schema <MethodCall id=1> <Name id=2 decl=42> <IDENT id=3 text="f"/> </Name> <LPAREN id=4 text="("/> <Args id=5></Args> <RPAREN id=6 text=")"/> </MethodCall> <!ELEMENT MethodCall (Name, LPAREN, Expr*, RPAREN)> <!ELEMENT Name (IDENT)> <!ATTLIST MethodCall id ID #REQUIRED> <!ATTLIST Name id ID #REQUIRED decl IDREF #REQUIRED>

  9. Encoding Program Text • Legacy tools may not want to understand XML: but it is not so easy to get to program text • One last refinements: simply mark up the source… <MethodCall id=1> <Name id=2 decl=42> <IDENT id=3>f</IDENT> </Name> <LPAREN id=4>(</LPAREN> <Args id=5></Args> <RPAREN id=6/>)</LPAREN> </MethodCall> • Don’t want structure? Strip off XML tags (with XSL!): <xsl:template match="/"> <xsl:apply-templates/> </xsl:template>

  10. Future Directions • Schema and grammar evolution • Schema will change with the grammar • Not really a problem: the grammar is abstract and rarely changes • Still, can use XSL to transform existing data to a new schema • Harmonia-enabled editor can generate transformations automatically • Incorporating version information • Need easy access to current version • Should be able to get to older versions • Data granularity for high level modeling tools • Need incremental refinement of detail

  11. Conclusions • An encoding satisfying all design requirements • XML-based (standard, convenient APIs, easy import/export) • Works for variety of tools • Can utilize many off-the-shelf XML tools/libraries • Programming language independent (DTD generated from language grammar) • More information • Harmonia web page: • http://www.cs.berkeley.edu/Research/Projects/harmonia • Email: • Marat Boshernitsan <maratb@cs.berkeley.edu>

More Related