Revision as of 14:56, 5 December 2006

Resource Modeling

For information regarding SML look here.

Next Meeting

Tuesday 12/5/06 @ 2PM EST/11am PST. Call in:

   US/Canada:  +1.866.432.9903    United Kingdom:   +44.20.8824.0117
   India:      +91.80.4103.3979   Germany:          +49.619.6773.9002
   Japan:      +81.3.5763.9394    China:            +86.10.8515.5666

Meeting ID: 2212316

If we need web conferencing: http://meetingplace.cisco.com/join.asp?2212316

Project Scope

• Import from SML-IF
  • Import an SML-IF document to an existing document repository. The open source implementation of the document repository will be a file system structure.
• Export to SML-IF
  • Create an SML-IF instance from existing document repositories. The open source implementation of the document repository will be a file system structure.
• SML and SML-IF validation
  • Provide a common interface for handling and reporting errors
  • SML validation
    • Provide a common interface for handling and reporting errors
    • A default implementation for the XML validation phase
    • A default implementation for the SML extension validation phase
    • A default implementation for the Schematron validation phase, which will include displaying results to a predefined output based on report/assertion conditions
    • Create a default validation scheme for the SML extensions: sml:acyclic, sml:targetElement, sml:targetType, sml:key, sml:unique, and sml:keyref
  • SML-IF validation
    • A default implementation for the XML validation phase
    • A default implementation for the Schematron validation phase in the context of an SML-IF document; includes displaying results to a predefined output based on report/assertion conditions
  • Apply the SML validation extension in the context of an SML-IF document: sml:acyclic, sml:targetElement, sml:targetType, sml:key, sml:unique, and sml:keyref
  • An implementation of RFC 3986 to resolve inter-document references within an SML-IF document
  • Verify that the SML and SML-IF validation implementations cover the test cases of the SML workshop scenario

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-v4.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.

back to home