XML-Demeter Project Description

We want to be able to use XML editors for modifying the Demeter Class Dictionary and Behavior. Eventually we would like to use the XML output for processing by Demeter Tools.

Advantages over using the old .cd files:

• we will be able to use a custom grammar (or custom parse sugar) once we will determine how the input maps to the Demeter.cd classes described in Generate.cd beginning with the root "Program". Future mapping and transformations from XML to .cd/XML will be easier than XML to .cd
• we will be able to use any XML editor for generating a .cd. Including visual "point-and-click" editors like Xeena.
• will be easier to process abstractions of the .cd. Example: see and work only with the interface classes or the parsed classes or visitor classes
• other advantages I didn't think about yet :)

Observation: most of the advantages exposed for XML over .cd are true for XML over .beh too.

Overall:

• we could store some .cd-s and .beh-s in the same XML file being able to view/process them in the classic .cd or .beh format at any time.
• the advantages here are those that are due to XML compatibility.
• the XML clearly maps over the DemJava's Generate.cd. Thus it can constitute a teaching tool for the Demeter Tools, source, and behavior.

• XML Spy for writing the Demeter.dtd and Demeter.xlt
• Xeena from IBM for creating the XML example inputs given the Demeter.dtd (downloadable from XML Visual Tools @ IBM alphaWorks)
• LotusXLT for XSL-Transformations with XPath (downloadable from XML Visual Tools @ IBM alphaWorks)
• a Web Browser for reading the .cd output

Presently we are able to use a visual "point-and-click" XML editor (Xeena from IBM) to create and modify an "XCD" (or a .cd file in XML format). Then we can take this .XCD file that is in fact an XML and apply the XSL-Transformation in Demeter.xsl to transform it into a Demeter "classic" .cd format.

Issues:

The present implementation has a number of bugs mainly due to certain present limitations. Here are pointers to the known limitations:

• XSL-Transformation Limitations
• XPath Limitations

Example of the present implementation:

• An example input .XCD file
• As for the DTD for the .XCD (may use only the part of Demeter.dtd that has its root at the "Program" entity
• The Demeter.xsl that guides the transformation
• The Xeena editor profile for the dtd
• the output in the Demeter classic .cd format
• A more impressive example of input and output

Short report on "structure-shyness" of XPath language:

For the purpose of this project I tried to make the XSL-Transformation processing as "structure-shy" as possible given it's present limitations. Here are couple of ways of achieving that:

• The main way is by using //Target : so the topology of the Class Graph can have the freedom to change while we are still able to get to the Target
  • used //Target1//Target2 to emulate Demeter's "via".
  • one can use //not Target1//Target2 to emulate Demeter's "bypass"
  • (for all these the source is the selected ELEMENT)
• by using /*/Target you can leave unspecified one hop from the source (you can select the grandchildren of the kind "Target")
  • you can use /*/ repeatedly to jump over more than one hop ex: /*/*/*/Target
• by using combinations of one or both ways within a path description ex: //Node1/Node2//Target will emulate a Demeter "via ->(Node1,Node2)" (via edge).

Some Goals related to the project:

• Short-term goals (due in 1-2-3 days)
  • improve this project description and report
  • try to find a way to output to a file WITH "<" and ">"
  • move these html files
• Long-term goals (couple of weeks)
  • do the .xsl for ProgramBehavior as a root
  • develop an automated system for editing-transforming-Java source generation-compilation process

   

Other ideas for project continuation:

• XSL-Transformation from any .XML or .DTD or DTD-Schema to .XCD rather than to .cd