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