[oXygen-user] Schematron validation "errors" enhancement

John Madden
Wed Nov 25 18:26:05 CST 2009


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:
> 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
> 
> http://www.oxygenxml.com/mailman/listinfo/oxygen-user

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.oxygenxml.com/pipermail/oxygen-user/attachments/20091125/3cb62f80/attachment.html 


More information about the oXygen-user mailing list