In Part 1 of this article (XML-J, Volume 4, issue 7) we outlined why a development group might consider alternative validation schemes. An example from our experience is applying work group rules to the process of XSD design. We said rules could take the form of a Schematron schema that would be applied when a developer validates an XSD against the schema for XSD. In our past work, a need existed for a productive way to put the alternative into play without losing familiar tools or disrupting current development patterns. For that reason we developed a simple multipass validation framework using XMLSPY's Scripting Environment. In this installment, we walk you through the scripting that remains to be set up and then look at how our framework can be a productive tool for your real-world use.

Finishing the Global Functions
At this point your "(GlobalDeclarations)" should include stubs for all the functions and global variables you have seen so far. They should have the same arguments and be in a form similar to what is shown in Listing 1.

Our implementation of these functions is uncomplicated, but there are a few areas to highlight, including where we use XMLSPY's object model and our use of the Windows Scripting Host.

We chose to read and write processing instructions holding validation commands because of the relative simplicity of using Altova's XMLData object; however, since most developers are more familiar with the DOM, let's take a closer look. Altova uses the XMLData interface instead of the DOM because the internal needs of developer's tools are unique and because XMLData can easily interoperate with the DOM (you can see examples of this in the XMLSPY Code Generator examples).

We factored code for finding all PIs into a pair of functions. The lack (on the public API, at least) of a count property giving advice on the number of children of an XMLData node is notable. Until this oversight is addressed, the easiest workaround is to catch the exception XMLSPY throws at end of the list (see Listing 2; Listings 2-7 can be found at www.sys-con.com/xml/sourcec.cfm).

"getAllPI" returns the set of PIs found at or below the node passed in. To get a reference to the root element of the current document you simply walk the object model starting at "Application".

var doc = Application.ActiveDocument;
var xml = doc.RootElement ;
var array = getAllPI(xml);

Another tricky point is where we save the document after adding a new PI in the "writePI" method. The fragment below shows how to create and insert the PI. Then, before you can save you need to switch into Grid view. We found that Text view did not save the document and update the view reliably. After saving we switched the view back, if needed, to avoid disorienting the user.

var doc = Application.ActiveDocument;
var xml = doc.RootElement ;
var newchild = doc.CreateChild( 9 );
newchild.Name = name;
newchild.TextValue = value;
xml.AppendChild( newchild );
var mode = doc.CurrentViewMode;
if ( mode != 0 ) doc.SwitchViewMode( 0 );
doc.Save();
doc.UpdateViews();
if ( mode != 0 ) doc.SwitchViewMode( mode );

Now you come to the Windows Scripting Host objects. Our framework uses WSH to get the XMLSPY install directory, read and write files, and execute validation commands. There isn't anything very difficult about using WSH in XMLSPY's Scripting Environment. The most important part is just knowing what objects are available and how to get a reference to an instance of one.

We created a two-line "getSpyPath" function to return the XMLSPY install path. The files your command and schema mappings are stored in are directly under this directory.

var shell = new ActiveXObject("WScript.Shell");
var value = shell.RegRead
("HKEY_CURRENT_USER\\Software\\Altova
\\XML Spy\\Setup\\InstallationDirectory");

Once you have a way to address the files, you need a way to read and write them. You will do this with WSH's "Scripting.FileSystemObject". We ran into a snag at this point. It's easy to get a handle to a file using WSH, but we were unable to use the "exists" method we found in online documents. Instead of testing for existence we worked around this with a conservative file create call that fails when the file exists, as shown in Listing 3.

Reading files involves an additional step. Once you have a reference to the file, use the "OpenAsTextStream" method and iterate over the lines, as shown in the fragment below.

var f = fso.GetFile( doc.GetPathName() );
var s = f.OpenAsTextStream(1);
var chars = "";
while ( ! s.AtEndOfStream ) {
chars += s.ReadLine();
}

Finally we get to the heart of the matter - executing validation commands. Again, the WSH call is straightforward. The "Wscript.Shell" object's "Exec" method returns a process object with a standard out stream. Every validation command must report through this stream so we can collect the output and present it to the user.

Additionally, it made sense to allow validation commands to include two delimited variables: "schema" and "doc" for the path to the schema and document files, respectively. You already created the simple form that presents the validation report. That form breaks the "validationMessage" string at every ";" character for readability. All this comes together in the lines below.

var shell = new ActiveXObject("WScript.Shell");
var doc = Application.ActiveDocument;
actual_command = replace( actual_command, "schema",
actual_schema );
actual_command = replace( actual_command, "doc",
doc.GetPathName() );
var pipe = shell.Exec( actual_command );
while( ! pipe.StdOut.AtEndOfStream ) {
out += ";" + pipe.StdOut.ReadLine();
}
validationMessage += out;

Setting up the framework
There are a few quick configuration steps to take before you are done with the scripting side. First, since we had a number of small WSH issues interfacing with the file system we found it easier to create the validation command and schema text files by hand. The scripts you can download will create these files as written but they may also fail with a permissions error while in the process of writing the new file. (With more time we may be able to work around this issue, but it hardly seems worthwhile right now.) In the XMLSPY install directory, probably "c:\Program Files\Altova\xmlspy", create "validation-cmds.txt" and "validation-schema.txt".

Next, in XMLSPY, click on the Tools menu and select "Options". Flip to the Scripting tab and check "Activate scripting environment when XMLSPY starts", "Run auto-macros", and "Process events". Also, if you are using our scripts, check that "JavaScript" is selected. Finally, make sure that the "Global scripting project file" field points to the scripting project file containing your code. Clearly, you also need to set up utilities for your validation commands.

Now, if you're using our project file, the next time you start XMLSPY and open a document, your multipass validation commands will appear on the Tools menu thanks to a showMacros call in the On_OpenDocument event handler. Every other member of your work group just needs a copy of the project, the command and schema files, and to configure their XMLSPY scripting environment as you just did.

That ends the hard part. The rest of the scripting work will be self-explanatory as you look at what we did. Now for the fun part - using the framework for multipass validation.

Validation Command Code
Before you create validation rules you need a way to execute them. Our Schematron utility of choice doesn't take much setting up. A simple but complete zvonSchematron driver could be as trivial as this .bat file:

c:\zvon\AltovaXSLT.exe -xml %1 -xsl c:\zvon\zvon\bin\
zvonSchematron.xsl -out c:\zvon\schema.xsl
c:\zvon\AltovaXSLT.exe -xml %2 -xsl c:\zvon\
schema.xsl -out report.htm

in which the arguments are a Schematron schema and the path to the document to be validated. Although this worked fine with our framework, it output more command-line feedback than we liked. Since the first step generates an XSLT file from the Schematron schema, you probably don't want to perform that step each time you validate a file. Removing the step also eliminates some of the noise. Also, since the framework doesn't want HTML, and we didn't want to hack on zvonSchematron, run zvonSchematron on your schema once, and modify the resulting XSLT for simple line-by-line output. Your batch file then becomes even more basic:

c:\zvon\AltovaXSLT.exe -xml %1 -xsl %2 -out %3

At that point it makes more sense to just add that as the validation command in this form:

c:\zvon\AltovaXSLT.exe -xml ~doc~ -xsl ~schema~ -out
temp.txt | more temp.txt

of course, using your own command-line XSLT processor. Your XSLT file generated by zvonSchematron from your schema needs to be added to your collection of schemas using the framework. Both the "~schema~" and "~doc~" will be swapped out at execute time for the full path to your schema and to your current working file, respectively (see Figure 1).

Example XML Schemas
Now that we have everything ready and our macros showing on the Tools menu in XMLSPY, we need XML files to test against. As we said, the goal is to make it easy for schema developers to meet a set of workplace guidelines for XSD.

Our scenario is this: multiple developers are creating new document types from an existing framework of developed XSDs. We wish to ensure that these new schemas fit established patterns. To understand the value of the rules being enforced by the Schematron schema, we need to discuss the framework XSDs.

First, the two included schemas: the file "root.xsd" gives the base type definition to be used for defining all root-level elements (see Listing 4).

At Classwell we often create new document types. Among these types we need a certain amount of commonality. Instance documents will be processed by a single tool set and used in the same application framework (perhaps with some customization for new types, but with substantial baseline functionality). The team cannot afford rewrites for every document type.

We follow patterns that guarantee our system will continue to work with new content without modification. However, as our company grows more content, work is done simultaneously, more people create new schemas, and enforcement of patterns becomes more and more valuable. We need to avoid merely saying "you have to know this and remember to do that."

One approach is to leverage the XSD type derivation mechanism. However, there are limitations to what you can enforce this way, and XSD cannot actually enforce any particular usage - this is what our first rule is all about.

So the example requirements are simple: the root element must have an "id" attribute and start with a "meta" element containing all the central metadata we care about. (Here we leave the space empty for brevity.)

The second schema is "para.xsd". This document defines the low-level text to be used in instances, within the document type-specific structure. Again this is left blank for brevity, but it would be defined to allow the sort of semantic tagging used to support rendering different styles, links, and so on, within paragraphs (see Listing 5).

Finally, we have an example of a XSD defining a specific document type, whose root element derives from "rootType" in "root.xsd" (see Listing 6). This document will pass all five of the tests we set up below.

Now we need a Schematron schema to enforce our rules. Each "rule" has a context and one or more self-documenting positive or negative tests. Positive tests are wrapped in a "report" element, negative in an "assert". A separate "pattern" is required if two rules inhabit the same context.

Altova: www.altova.com

Published Aug. 6, 2003— Reads 13,634
Copyright © 2003 SYS-CON Media, Inc. — All Rights Reserved.
Syndicated stories and blog feeds, all rights reserved by the author.

Related Links

▪ Figure 1

▪ Source Code

About David Kershaw
David Kershaw is the professional services manager at Altova, Inc., the XMLSPY company. David brings 11 years of software engineering, project, and product management to Altova. His previous positions include serving as the Director of Engineering at Classwell Learning Group and the Group Director of Engineering at Organic, Inc. David received his master's degree from Harvard University and his bachelor's degree from the University of Massachusetts.

About Eric Schwarzenbach
After working in software development in various industries over the past decade, Eric Schwarzenbach eventually came to specialize in electronic publishing. The issues of document-oriented XML are his focus: document and knowledge modeling, processing, and management frameworks, as well as XML databases and searching. He's written custom document management systems and worked with native XML databases such as Tamino. He currently serves as the unofficial Tamino XDBA and content engineering lead at Classwell Learning Group.