A simple test of XPath filter performance

Hello all,

Joseph asked me to send to the list an example to illustrate the type of performance needed from the XPath filter.

At 95K, the attached XFDL form would be considered small by PureEdge standards.  The typical form is around 200K to 300K, and the signature filters tend to be more complicated.  However, I have the impression that this document has similar signature filters to those used to test reference implementations and is over twice the size of the typical test data being used to test current reference implementations.

If you want to get an idea of the processing performance of the current PureEdge signature filters on this document, you can download a free trial version of the PureEdge Viewer using http://www.pureedge.com/downloads/viewer/index.php and also obtain a certificate from Verisign or Thawte or some other CA.  Once you have these things, you will be able to load attached form and press the signature button.  If you have multiple certificates, you will be asked to choose one.  The filtering process happens after you have a certificate selected.

On the attached form, you will see no more than a half second delay (assuming a 500 MHz pentium III, which is quite reasonable).  It is important to note what actually gets done in this half second.  The PureEdge software performs both a sign and validate of the form.  The sign operation includes signature filtering, canonicalization, hashing and private key operations.  The validate operation includes another signature filtering, another canonicalization, hashing and public key operations.  This, of course, is why I am concerned about reports of 10 or 20 second run-times just to filter a 40K block of XML.

Even assuming that the entire half second were used to perform only the filtering operation twice, the attached form with equivalent XPath filters would have to filter in about a quarter of a second on a 500MHz machine.  If the current implementations are able to do this, then we may be in good shape after all (though I would at that point provide a 'normal' sized form for benchmarking).

FYI, there are two signature filters on this form, the net result of which is to sign the entire form less some subtrees.  The first filter eliminates all elements at depth 3 with a tag name of 'triggeritem'.  The second filter, called signitemrefs, omits six subtrees at depth 2.  The 'sid' attribute is used to uniquely identify pages (depth 1) and items (depth 2).  The identifiers in the signitemrefs filter are

				PAGE1.CHECK16
				PAGE1.CHECK17
				PAGE1.FIELD47
				PAGE1.BUTTON2
				SIGNATURE2
				PAGE1.FIELD48

The PAGE1 indicates a 'page' element with a 'sid' attribute of PAGE1.  CHECK16 is the scope identifier, or sid, of a checkbox on PAGE1.  When the page is not given, the current page is assumed, though I would be fine with an XPath filter that identified PAGE1.SIGNATURE2 rather than using here().  Without looking at this in great detail, the subtrees to be deleted probably have an XPath filter 2.0 expression along the lines of 

	/XFDL/page[@sid="PAGE1"]/*[@sid="CHECK16" or ... or @sid="FIELD48]

The other subtraction filter would probably have an expression along the lines of

	/XFDL/page/*/triggeritem

Finally, if you want to see exactly the XML being signed by the PureEdge product, press the signature button to bring up the signature dialog, then press the Advanced button to bring up a dialog that will give you the XML in a text field.

Thanks,
John Boyer