Implementation details

SML/SML-IF Validation & Editor

Design

The following attached document describes the validation of SML/SML-IF documents. It also includes description of embedded editors in Eclipse: Media: SML-Validation-v7.pdf

Implementation (in progress)

The following attached zip file is a copy of the source files: Media:Backup-v2.zip (your browser may not pick up the latest copy if a previous attachment has been cached)

Nov 21st/2006 update

An informal meeting between Valentina, Sheldon, and I (Ali) resulted in the following design decisions:

• Sheldon already has a prototype of performing the first and last phase of the validation (i.e. XML validation against a schema and schematron). The schematron validation phase is based on version 1.5. This phase uses the skeleton1-5.xsl( http://xml.ascc.net/schematron/1.5/) reference implementation to extract the schematron from the schema.
• I have completed the validation output, which will be dependent on the environment where the validation process will be performed. In Eclipse the validation output will be a set of markers that will be written to the problems view. In the standalone mode the user will have the option of either logging to a file or system output.
• The second phase of the validation process was discussed. Some SML extensions require their own data structure to perform the validation. For example:
  • sml:acyclic will require a directed graph where nodes represent documents and edges represent the source and target element from/to the document that contains them.
  • sml:targetType will require an inheritance tree representing the relationship between the different element types.
• Sheldon is working on a general SAX parser that will allow a set of content handlers to be registered to construct the different data structures required as part of the validation. This will allow us to generate multiple data structures by parsing the XML document once. Each data structure is registered with a class so that it can be retrieved and used by other SML extensions.
• I'm currently working to generate the directed graph needed as part of the sml:acyclic validation.
• Valentina is continuing with her tasks (validation of SML identity constraints: key, keyref, and unique)

Nov 23rd/2006 update

Sheldon has completed the generic parser that allows multiple data structures to be created through one pass of an XML document. The structures are registered and retrieved via a unique ID. Also, the validator factory classes were revised after I discussed them with Sheldon.

I have completed the data structure builder for the directed reference graph that will be used as part of validating the acyclic extension. A structure is also created to determine the types that are declared as acyclic. A partial implementation of the acyclic validator is checked in. Here's how it performs the validation:

for every element i declared as acyclic
  G = obtainReferenceGraph(i);
  backEdge = DFS(G);
  if (backEdge == null)
    no cycle found;
  else
    use backEdge and tree edges to report the cycle detected;
    report error;


Nov 28th/2006 update

The DataBuilder was updated to include a concept of validating the data strucutre that is generated. JUnits were created to cover all 5 acyclic scenarios of the interop workshop:

• InValidCycles.xml, ValidCycles1.xml, and ValidCycles2.xml are handled by test cases under org.eclipse.cosmos.rm.validation.tests\junits\TestAcyclicValidator.testsuite
• InValidDerivation.xml and ValidDerivation.xml are covered by test cases under org.eclipse.cosmos.rm.validation.tests\junits\TestTypeInheritanceDataBuilderImpl.testsuite

An abstract class was created for all property extractor data builders (i.e. data builder that extract an attribute name from an element that meets a set of criteria).

Dec 4th/2006 update

An informal meeting was held between Valentina, Sheldon, and I (Ali) to provide a status update. There was a discussion about how the key/unique sml extensions should be validated. There appears to be a need to store the DOM fragments of some of the documents in order to perform key/unique extension validation. Sheldon questioned the current approach of doing SAX and DOM parsing. The design was justified after realizing that the hybrid parsing method is needed to satisfy the needs of all sml extension validators. A high level algorithm was derived to perform the key/unique extension validations. Valentina will look into APIs available to evaluate XPath expressions, which is required as part of the derived algorithm. There were concerns raised by Valentina about not taking namespaces into account while building the required data structures. Since then, I have updated some of the data builders to build namespace aware structures. Sheldon is doing the same for the data structures required by his validators.

Dec 13th/2006 update

Added APIs to be able to evaluate XPointer expressions. The supported expressions are:

• Full Expression
• Child Sequence
• Bare Name

Only two schemes are supported for full expressions: xmlns and xpointer. The default functions of xpointer are not implemented (since they are not allowed in SML documents). I have added JUnits to exercise the XPointer APIs. The xpointer scheme is using Xalan to evaluate the XPath expression. We will eventually need legal clearance for using Xalan (or any other equivalent API) in COSMOS.

Dec 14th/2006 update

Finished implementing the XPath extension function, deref(). To use the deref function the client code must use ISMLCommonUtil.xpath and set the correct namespace context before compiling an expression. The xpath instance variable has a registered XPath function resolver which invokes the deref implementation when it is detected. Here's an example of how to use the function:

SMLCommonUtil.xpath.setNamespaceContext(<A namespace context>);
XPathExpression xpathExp = SMLCommonUtil.xpath.compile("smlfn:deref(tns:EnrolledStudents/tns:EnrolledStudent)");
NodeList nodeList = (NodeList)xpathExp.evaluate(<Context node>, XPathConstants.NODESET);

See the internal documentation of org.eclipse.cosmos.rm.validation.internal.reference.DerefXPathFunction for more details. The JUnit test that exercises this class is under org.eclipse.cosmos.rm.validation.internal.reference.TestDrefXPathFunction.

The builder used to construct the DOM nodes for phenic documents is now constructed as part of the SAX parsing. The builder used to construct a DOM document by parsing the document once and walk through the DOM document to extract what was needed. The new builder avoids the parsing and traversal of the DOM document.

Jan 3rd/2007 update

With the exception of the 'rule' scenarios, all other workshop interop scenarios are now covered with JUnits. The main validator can also be executed as a standalone Java application using the following syntax:

org.eclipse.cosmos.rm.validation.internal.core.MainValidator ([option][option argument(s)])* <path to XML document>, where available option and arguments are:

• -xml <a fully qualified class name>
• -sml <fully qualified class names separated by a comma>
• -schematron <a fully qualified class name>
• -ouptut <path to the output file>

It's recommended to run the class in Eclipse to avoid manually adding the required jar files to the classpath.

Jan 30th/2007 update

The SML-IF editor is complete. See the implementation section to download a copy of the projects. Defects can be reported using COSMOS bugzilla.

Feb 12th/2007 update

The SML-IF import/export wizards are complete. These are fully integrated with the Eclipse import/export dialogs, and can be found under the Service Model Language category.

See the implementation section to download a copy of the projects. As before, defects can be reported using COSMOS bugzilla.

Feb 19th/2007 update

The code for SML-IF validation, editor, import, and export is now being kept current in the eclipse CVS repository. From now on, please access the latest code there instead of using the Backup-v2.zip file linked earlier on this page. Here is cvs access info:

:pserver:anonymous@dev.eclipse.org:/cvsroot/technology

From there, go to org.eclipse.cosmos/resource-modeling