Re: logic error in iso draft?

Brian Ewins wrote:

> Something that cropped up in testing... I used a random xml document 
> and a minimal schema and it was reported as valid. Oops.
>
> The reason was that no assertions failed, because no rules fired 
> (which was correct for this schema/instance combination), so there 
> were no failed assertions, but no /passed/ assertions either. I 
> checked the draft to see if I'd made a mistake with the semantics, and 
> I can't see it. Should sec 3.4 should be changed from reading:

That is an interesting point.

XML Schemas has a similar issue: especially in lax mode, if your 
document uses a different namespace than the schema (due to an error, 
for example) then it may be reported as valid. That is really bad. RELAX NG
has a "grammar" element to specify the allowed roots of a document.

In Schematron, if you want to say that a structure is required, you have 
to make it a pattern in the
context of something that is guaranteed to be always there.  
context="/*" for example.  In other words,
in the Schematron worldview, the fact that some element must exist is a 
pattern; if there is no assertion
made that, in the context of the whole document (or its root element, 
acting as the context) there should
be some element existing, then there is no assertion.  Schematron is 
open by default. 

<pattern id="roots">
  <title>Allowed Roots</title>
  <rule context="/*">
    <assert test="/a or /b or /c or /d">
       Only the following elements are allowed at the top-level: a, b, c, d
    </assert>
  </rule>
</pattern>

> "An instance document is valid if no assertion tests in fired rules of 
> active patterns fail."
> to
> "An instance document is valid if no assertion tests in fired rules of 
> active patterns fail and at least one rule fires." ?

Hmm. I am not sure, but I do take your point the fact that no contexts 
were matched may be of interest to
users sometimes, especially when flying solo.

I would be very reluctant to call this "invalid" because Schematron is 
positioned to work as an
ancilliary to grammar-based schema languages (DTD, RELAX, XS, etc.): so 
it is quite possible that
a document may not have elements that the Schematron schema covers. For 
example, a Schematron
schema that checks CALS table's  column count would not be called when 
there is no table in the
DOCBOOK (for example) document, but it is quite legitimate for a DOCBOOK 
document to have
no tables.

Also, we have the "phase" idea, in which we want to just check certain 
constraints now, and then
check others at some other stage. It is difficult to see how to make 
that work effectively if
no fired rules=invalid, because we are explicitly not attempting to test 
some things each time:
the document may be unfinished for example.  You would have to put in a 
dummy pattern for each
phase with context=/* and  test="true()" for every phase, which would be 
cumbersome.

> So: should I report no assertions being tested for an instance as a 
> valid document, an invalid document, or an error?

It would be a valid document. But why not support an invocation mode 
"require at least one rule to fire" that
generates an implentation-specific message: an enhancement that makes 
your implementation friendlier to use. 
It would be a nice feature, and doesn't require any changes to Schematron.

The valid/invalid distinction in Schematron is probably the least 
interesting possibility it affords: it is the ability
to let the user find the presence or absense of  patterns in a document 
that is important, and signalling to the
user that no rules fired fits in with that goal. We don't want to fall 
into the trap of making valid/invalid carry
too much weight, if you know what I mean. In fact, a document might be 
invalid but perfectly acceptable to
the user, a non-strict HTML document being validated by a strict schema, 
for example.

In the working draft ISO standard, everything is couched in terms of 
valid/invalid because that is the way to get a
minimal spec and because it is the bottom line required for fitting into 
ISO DSDL and people's expectations
of what a validator does: but you can see from all the ancilliary 
elements and attributes in Schematron,
I think that YES/NO validation is not really the bottom line for 
usability and usefulness to humans. This is based
on 15 years of using SGML/XML and as a vendor of validation systems: 
people have a real problem with
automatically-generated error messages. In SGML and XML I believe this 
is because often an error is
detected far away from where it was caused; consequently people learn to 
disbelieve error messages because
their messages are so frequently wrong. In Schematron, it becomes the 
schema-writer's (and, to an extent, the
implementor's) job to make sure their assertions and diagnostics are 
communicative: they are in the
best position to know.  In that sense, Schematron could be considered as 
a kind of highly abstracted
user-interface specification language, like XUL or XAML :-)   (Contrast 
this with Xerces, where you have
to recompile if you want different error messages.)   One of the 
benefits of the disjunctive behaviour of rules
in patterns, and with phases, is that it allows the prudent schema 
writer to zero in exactly on where the problem
occurred and report the problem in specific terms, not in abstract terms 
of content models.

I hope this is some help.

Cheers
Rick Jelliffe


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click