9 Goals from WAS XML ?

These are my thoughts on some goals from the perspective of someone who has looked at VulnXML, and focusing on the part
of the signature that describes the sequence of test operations (ie not the classification scheme or risk ranking model).

Improved i18n/localization Support
A good deal of human readable text is contained in the signature; the format needs to support the provision of this
text in multiple languages.

Richer Core Functionality
In order for the signature to support a more diverse set of tests, the format needs to support a wider range of operations,
such as scoped variables, enhanced conditional logic, repetition.

Improved Code Reuse Mechanism
There needs to be a way to for WAS-XML signature authors to package common functionality for reuse in many places within a
signature or in many signatures. Need subroutines, functions or methods, and an inclusion mechanism.

Improved Extensibility
It must be possible for a 3rd-party to extend the functionality offered in the core WAS-XML feature set. The extensibility
mechanism could be modeled on the one used in XSLT.

Structured Extended Output Information
Tests need to return more than pass/fail -- there should be structured (machine-readable) sections and loosely-structured
sections (human-readable information). More information is needed so that systems and users can, if needed: determine cause
of test failure, determine if result is really benign/malignant, understand details of test processing. The information
needs to be structured so that a system can present the information in a meaningful way or perform further processing on
the data.

Tighten Schema
It looks like this is already happening as part of WAS-XML (classification XML Andy Jaquith started) , but the more
restrictive the schema can be made, the more easily documents will be
processed and authored using standard XML authoring tools.

ApplicableTo Element
Running only the tests that are applicable to a given platform/OS/web server/application should yield considerable
performance and coverage
benefits in an enterprise-class system. It is important that WAS-XML signatures have an ApplicableTo-like section so that
systems can optionally try to run only the signatures judged to be applicable. However, the VulnXML ApplicableTo element
and its sub contents can be quite complex -- for the WAS-XML Signature author perhaps too complex. I wonder if it might
be possible to create a simpler but equally expressive alternative to the VulnXML ApplicableTo element.

Less Novel Approach
VulnXML essentially defines its own simple procedural programming language. As Jeff and others have pointed out this is
crucial in testing. I believe the language must necessarily become more complex to cover the range of web application
testing scenarios. Rather than extend a new and relatively unknown programming language, why not adopt an existing
programming paradigm (XSLT or JSP+custom tags) or adopt a widely used programming language (JavaScript)? XSLT would be my
strong preference although we may wish to support several.

Integrity of Signature
A mechanism to proove that the signature originated from a trusted source and has not been modifed. XML Dig SIg ?

was message