Wendell, I agree with you about oxygen's current usage as being an interpretation that is over and above what the Schematron spec actually says. I have to admit that I really like being able to distinguish between errors and warnings, so I do like the fact that oxygen has foreseen a need for this. In addition to the approach of embedding severity information using some convention inside error messages or diagnostics, I can think of a couple of other ways to approach this. (1) Associate error severities with different phases (<sch;phase>). I'm not sure how you pass phase requests to the schematron processor inside oxygen (George?), but this strikes me as a really nice way. You could then run the same schematron file against the instance multiple times invoking one phase for warnings, another phase for errors, etc. You might associate a particular phase to a particular kind of display in oxygen up in the <?oxygen... processing instruction that calls the schematron. So say you have a schematron schema that defines two phases, "warning-phase" and "error-phase". Then you'd associate it twice with your instance (maybe with the help of some new options in the Associate Schema dialog tab for schematron), ending up with two PI's attached to your instance, that might look like this: <?oxygen SCHSchema="example.sch" phase="warning-phase" display-as="warning"/> <?oxygen SCHSchema="example.sch" phase="error-phase" display-as="error"/> (2) For ISO Schematron, another approach might be to support "flag" attributes on assertions and rules. The ISO schematron spec states: "The purpose of flags is to convey state or severity information to a subsequent process." so it's my reading that a distinction such as between warning and error was one (of many other kinds) of thing that flag attributes can address. You'd have to have some way in oxygen of stating that a particular flag-name was intended to be associated with errors and another with warnings. I personally like phases better than flags for this. Just some thoughts. John On Nov 25, 2009, at 2:47 PM, Wendell Piez wrote:
Hi,
Currently, Schematron is regarded by oXygen as a validation technology, and it uses many of the same interfaces as XSD, RNG and DTD, including having its results reported in a validation results window.
This is fine, but additionally, a distinction is made between Schematron messages emitted by Schematron 'assert' elements and those emitted by 'report' elements; the latter are classed as warnings, not errors. They are formatted differently, with a yellow icon instead of a red one, plus the word "warning".
However, in my experience working with Schematron, more often than not this distinction does not hold. "Errors" or "warnings" or simple "alerts" or messages of any status whatever can be the results of either a Schematron 'assert' or 'report'; that is, which Schematron element is used to generate a message has nothing to do with the severity of the condition being reported. Or even whether it's good or bad: sometimes the message emitted by either an 'assert' or 'report' represents not failure but success.
I wonder if in oXygen, this distinction could be removed, and the results of all Schematron assertions (both 'assert' and 'report', i.e "positive and negative assertions of a constraint") could be represented the same.
If you really wanted to get fancy, the status of a Schematron message in oXygen might be configurable. Maybe the assignment of "error" or "warning" (or whatever else: blue or green icons?) could be made on the basis of a regular expression matching the message. It's pretty common practice for Schematron messages to be internally structured with their own language about errors, warnings, alerts, info, etc., with structurer error codes and the like.
The same thing applies to the inline iconography, i.e., having errors from 'assert' underlined in red in the editor view, while 'report' results are colored yellow.
For Schematron developers who are deploying oXygen as a validation platform for non-experts -- who are sometimes prone to be alarmed unnecessarily by iconography -- it would be really nice to be able to control this.
If not, I think oXygen might at least be neutral on the question of which Schematron messages are at which level of severity.
What do you think?
Cheers, Wendell
====================================================================== Wendell Piez mailto:wapiez@mulberrytech.com Mulberry Technologies, Inc. http://www.mulberrytech.com 17 West Jefferson Street Direct Phone: 301/315-9635 Suite 207 Phone: 301/315-9631 Rockville, MD 20850 Fax: 301/315-8285 ---------------------------------------------------------------------- Mulberry Technologies: A Consultancy Specializing in SGML and XML ======================================================================
_______________________________________________ oXygen-user mailing list oXygen-user@oxygenxml.com http://www.oxygenxml.com/mailman/listinfo/oxygen-user