Subject: Conformance, Flag, Role/Subject - msg#00015

Daniel Cazzulino wrote:

Cool. I'm working on ISO Schematron.NET :D. I'm really tempted to move it to
the Mvp.Xml project, which is gaining momentum.


That would be great!

I'm a bit worried about the schema/@language attribute. You see, EXSLT.NET
can be used in pure XPath code, so I can support it. But in this case, I
don't support xslt binding. I do support xpath binding, however, and that
may imply the exslt binding subsumes it. I'm not sure if exslt is also
considered to subsume xslt. I guess I'll have to let the validation blow if
the language is exslt and some XSLT construct is used :(

Since EXSLT is a superset of XSLT in this regard, it does subsume. So you can implement
default processing using EXLST processing.

A "simple conformance" implementation does not need to detect that its XPath
use EXLST extensions even though it claims to be using the default XSLT. (However,
of course, it its implementation did not understand EXLST we would expect
some kind of exceptional behaviour to be implemented.) See section 8.1

A "full conformance" implementation is expected to also check the grammar of
the bindings: in that case, using EXLST extensions in a document claiming
to be the default XSLT must generate an error or exception.

So the "simple conformance" is quite a low bar to encourage implementation
and for the Desparate Schematron Hacker, and the "full conformance" is quite
a high bar to allow industrial-strenght implementations.

I'd also like further clarification on the purpose of role/subject, as well
as the flag attribute. I know these are optional, but I want to be as
conformat as I can.


FLAG
--------
The flag attribute meets a UK requirement that validation using Schematron
should be useful in situations where you really want to end up knowing
the "state" of the document, rather than just having a boolean valid/invalid,
or a set of messages, or a set of extra labels on the document's nodes, or
a set of external links pointing to nodes.
Whenever an assertion that has a flag fails, then an implementation
can add to some set (or bag, it is implementation-determined)
that flag. So you might have a flag "fail-with-error" (rather than
"continue-with-warning" for example); if an assertion
with that flag fails, then at the end of validation, the user (or resulting
process) can have reported to them that information. (It could
be linked to the node that caused failure, it could be just a simple
fact, that is all implementation-dependent: I hope some conventions
will arise if it is useful.)

An implementation might also define, or have extension elements/attributes
for, or have a little-language or configuration for, a mapping
between flags and actions. For example, a flag might be
"REPAIR-ME", which the implementation uses as its key to
point the user to something that they should fix. Or a mapping
from flags to methods/functions in a particular language.

So the purpose of "flag" is to provide a way to annotate or signal
the state of some document or particular nodes, to allow some
subsequent action. But to do this in a declarative and language-independent
way. In many cases, where people might want to put an "action"
attribute or something similar, which then calls a script or method
in some language by name, the flag attribute provides a little
abstraction.
Now, of course, it is fine to add elements or attributes in your
own namespace for extensions, actions and so on. But it was
felt that since several people have used Schematron to extract
state information about a document and to trigger actions,
ISO Schematron should provide something small, non-required
and relatively clean.
The more that language-dependencies (such as JavaScript scripts,
.NET methods in X++, Java methods, etc) can be removed to other
layers, the more that implementation-independent schemas can
be developed.
So if you implement flags I suggest:
1) There should be an option to turn on or off flag processing

2) There should be a simple list of flags available, just as a simple
map, where the user just knows "was flag X every set during
this validation?" (Flags can not be unset, by the way.)

3) To be really useful: information on any assertion failure reports that
say if a flag failed for that element, *or* information on each
flag pointing to each node that failed

4) Some mapping system of your own devising to map
some kind of .NET (I presume) actions to the flags.
I guess you should define some signature for this,
passing the document, the subject node, the flag,
and the assertion, or whatever. Some use cases might be
flags for "notify-sender" and "notify-recipient" which
email the results of failed validation to the programmers
responsible for the server and the client; or a flag
"scam" which might divert the message along
some alternate path to the security division; or
a flags "user-required" which causes an invalid document
to be returned to the user requesting that they complete
a form (This is similar to Peter Sefton's use from a couple
of years ago, where Schematron was used to allow validation
of forms on a server, with assertion failures used to generate
information used to generate new forms.)

ROLE
---------

The purpose of the role attribute is to allow the labelling of
nodes within a pattern. This is more useful for "screen-scraping"
applications (where you report on what you found in a
document) rather than for validation. For example, when
generating RDF or topic maps, you can use the role attribute
to label what the arc is between elements (this is what
Schematron-RDF uses.)
Because ISO Schematron is a validation specification, the role
attribute has not been given much prominance.

For validation, the role attribute can act as additional documentation
for each rule, etc, that might provide some useful information
to users, if shown. If a Schematron schema validation result was
drawn overlaid over a tree of nodes, for example, so that you could
iterate through each pattern than matched and see all the context
nodes of that particular pattern match, it would be useful for users
to see the role that each node was playing in that pattern, for example.

But role, flag, subject, icon, see and most of the other attributes are
ancilliary: you should feel no compulsion about not implementing
them, unless they fit in with your use cases. On the other hand,
I encourage you to implement them (rather than home-made
alternatives) whenever they *do* fit in with your use cases.

SUBJECT
--------------
The subject attribute is required because sometimes what an assertion
is about is not actually the context node. The context node may
just be the most convenient pivot for the Xpaths. So the subject
attribute provides a way of saying "well, this assertion failed
in this context, but *here* is the thing that is wrong".
Assertion tests return boolean, not necessarily nodes, so we
cannot use the results of tests.

I would tend to think that the subject would be evaluated on
request (i.e. passed to the error handler as a text string with
its context node) rather than always evaluated, to prevent
unwanted processing.

An example might be this:
<rule context="order/person[@name]">
<assert test="//address[@authorised='true']/person[@name=current()/@name]"
subject="../order"/>
All orders must come from a person with an authorized address
</assert>
</rule>

In this case, the context node is the person, however, the node that we want
to make the subject (to reflect the assertion text) is the order itself.
You can see that this fits in with flags: it allows us to specify more
precisely, where necessary, the node that might be used for
repair or reporting.

Again, the intent is to be declarative: to reduce the amount of knowledge
of the document's structure that is required by some program that
makes use of the validation results.

ISO Schematron only can standardize on validation aspects: finding
the presence or absence of patterns. The subject, role and flag attribute
allow more specific reporting and signalling, and are resources that
subsequent implementation-specific processing can make use of.

I hope these are some use
Rick Jelliffe


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com