Difference between revisions of "COSMOS Design 237921"

Revision as of 13:36, 24 June 2008

Support PSVI in SML Validation

Change History

Workload Estimation

Terminologies/Acronyms

The terminologies/acronyms below are commonly used throughout this document. The list below defines each term regarding how it is used in this document:

Purpose

This enhancement is associated with bugzilla 237921.

The purpose of the feature is to add support for PSVI to data builders used in constructing structures required for validation of SML constraints. Currently the validator parses through each definition document to determine element types, their derivation and any associated SML constraints. Manual parsing of definition documents negatively impacts performance and memory consumption required by the validator. Another disadvantage of manual parsing is the inability to cover all possible cases. There are unpredictable methods of how schema can be used. It's preferred to rely on an established interface as opposed to manually parse through each schema document.

What is PSVI?

Post Schema Validation Infoset (PSVI) is the ability to access schema-level information when parsing an XML document. The interface set is available via DOM or SAX. The snippet below describes how the PSVI provider can be retrieved when SAX parsing a document:

SAXParserFactory saxParserFactory = SAXParserFactory.newInstance();
saxParserFactory.setFeature("http://apache.org/xml/features/generate-synthetic-annotations", true);
saxParserFactory.setFeature("http://xml.org/sax/features/validation", true);

SAXParser newSaxParser = saxParserFactory.newSAXParser();
newSaxParser.setProperty("http://java.sun.com/xml/jaxp/properties/schemaLanguage", "http://www.w3.org/2001/XMLSchema"); 
newSaxParser.setProperty("http://java.sun.com/xml/jaxp/properties/schemaSource", <LIST OF SCHEMA INPUT>);					
			
PSVIProvider psviProvider = (PSVIProvider)newSaxParser.getXMLReader();

Assuming the presence of psviProvider, an element or an attribute declaration can be retrieved using psviProvider.getElementPSVI() or getAttributePSVI(...). The following snippet of code determines the base type for the current element:

ElementPSVI elementDeclaration = psviProvider.getElementPSVI();
XSTypeDefinition typeDefinition = elementDeclaration.getTypeDefinition();
System.out.println("The base type of the current element is: " + typeDefinition.getBaseType().getName());

The following code is used to determine if sml:acyclic is set on the current element. The code retrieves the annotation of the type associated with the current element to determine if the attribute sml:acyclic is set:

ElementPSVI elementDeclaration = psviProvider.getElementPSVI();
XSTypeDefinition typeDefinition = elementDeclaration.getTypeDefinition();
		
XSObjectList annotationList = ((XSComplexTypeDefinition)typeDefinition).getAnnotations();
	
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();            
Document domDocument = factory.newDocumentBuilder().newDocument();
		
for (int i = 0, annotationCount = annotationList.getLength(); i < annotationCount; i++)
{
   XSObject annotation = annotationList.item(i);			
   ((XSAnnotation)annotation).writeAnnotation(domDocument, XSAnnotation.W3C_DOM_DOCUMENT);
   Node acyclicAttribute = domDocument.getFirstChild().getAttributes().getNamedItemNS(ISMLConstants.SML_URI, ISMLConstants.ACYCLIC_ATTRIBUTE);
   if (acyclicAttribute != null)
   {
      System.out.println(acyclicAttribute.getNodeValue());
   }
}			

Implementation Detail

All data builders used to construct structures based on definition documents are expected to be replaced with PSVI. There are currently three phases to the validation process:

1. Constructing the data structures required by each validator
2. Executing validators to verify SML constraints
3. Checking schematron constraints

A validator is currently used to register a set of data structures it requires for validating a constraint. The data builder associated with a validator are content handlers that are invoked when parsing through an SML-IF document.

The first and second phase will be affected by this enhancement. The SMLMainValidator will be modified to parse through an SML-IF document using three different content handlers:

1. HeaderContentHandler
2. DefinitionContentHandler
3. InstanceContentHandler

HeaderContentHandler is used to determine the identity, rule binding, and the schema binding of the SML-IF document. The structures build by this content handler is used later during the parsing process to bind definition documents with instance documents.

DefinitionContentHandler is used to gather all schemas that are to be used when validating instance documents.

InstanceContentHandler schema parses each instance document to build the data structures required for validating the SML constraints.

Once the document content is parsed, SMLMainValidator invokes each validator to check the state of each constraint.

Graphical View

The top most section of the view will consist of a graphical representation of the response. The section will leverage dojox.gfx APIs along with atomic shapes to render a graph. The APIs use SVG in FireFox and VML in IE to render the individual shapes. The end result is a static diagram with cross-browser support.

The image below shows a sample of what the graph will look like:

File:Graph response visual.png

The graph layout algorithm renders adjacent nodes closer to each other. This will visually indicate entities that are closer together in relation. The radius of each node is determined by its order (i.e. outgoing edges from the node) and the color of the node is dependent on the template it belongs to. Notice a legend is displayed at the bottom of the diagram.

The graph layout algorithm is not sufficient for responses with many items or relationships. The graph is best suited for 30 or less nodes with a maximum node order of 3. The graph view will not be generated if this condition is not met. A warning will be displayed and the space will be reserved for the logical representation (see next section). Users will have the ability to discard the warning and display the graph if they choose to populate the view.

The image below displays a concrete example based on data from the student-teacher MDR. The value of this graphical overview is the ability to quickly identify relationships between two different entities. Using this diagram, the user is quickly able to identify the following relationships:

• Staff01 teaches Student01 and Student03
• Staff02 teaches Student01, Student02, Student03

Logical View

A tree structure is provided to allow traversal of the response elements. Unlike a grid structure, a tree will only occupy the space needed. The properties view will be used to display any fields associated with a selected tree node. The image below provides an overview of the tree structure:

Each level of the tree is described below:

• First level: item/relationship template ID
• Second level: the first item/relationship local ID
• Third level: record ID

The properties view will be populated based on selection of nodes. The following fields will be displayed for each tree item selected:

Double clicking a record will open a dialog box with the XML content of the associated record.

Task Breakdown

The following section includes the tasks required to complete this enhancement

1. Isolate the query response view as a separate test page (the one that currently exists is outdated) [complete]
2. Define a structure to be used by the graph layout algorithm [complete]
3. Modify outputters to generate the structure [complete]
4. Create the graph layout algorithm [complete]
5. Write code to render the graph [complete]
6. Define a structure to be used by the logical tree structure (determine if the same structure as the graph layout can be used) [complete]
7. Modify outputters to generate the structure [complete]
8. Create a tree based on the structure [complete]
9. Decorate the tree items with icons
10. Use topic publication/subscription to detect tree item selections [complete]
11. Populate the properties view based on the selection [complete]
12. Create the overall layout of the view [complete]
13. Add the graph and logical component to the main view [complete]
14. Determine how to add this as an alternative view to displaying the CMDBf query response

Future Direction

• Showing direction of relationships in the graph view
• Displaying edges only when user hovers over a node
• Adding additional interaction (e.g. display information when hovering over a node)
• Once COSMOS has the capability of adding user profiles, add the ability to disable parts of the view users may not be interested in.

Open Issues/Questions

All reviewer feedback should go in the Talk page for 224166.