Remove or reformulate statements about natural-language text about schematron-enhancement-proposals HOT 11 OPEN

from schematron-enhancement-proposals.

I think the crux of Erik's argument is this (correct me if I'm wrong, @xatapult ):

any other usage is prohibited, but we can't enforce this

-- but I appreciate Rick's argument and the intention behind expressing this usage as a normative part of the standard.
So I would agree with not changing the existing text, but I think it would help implementers to include a note that conformant implementations are not expected to enforce this. My (limited) understanding of the state of the art is that this would likely be a tall order, and is probably outside the scope of an implementation anyway. Thoughts?

ISO DSDL should add a non-normative annex

@rjelliffe , just to clarify: did you mean adding this to ISO/IEC 19757, or specifically to part 3 only?

from schematron-enhancement-proposals.

from schematron-enhancement-proposals.

I think that changing "shall" to "should" and providing a rationale for, and examples of, positive statements could satisfy this proposal.

Give that @xatapult quoted from the Schematron standard, it's fair to say that he has read it. I would hazard that he has read it more and more often than most people.

Individual ISO standards don't define their keywords, but https://www.iso.org/foreword-supplementary-information.html includes:

• "shall" indicates a requirement
• "should" indicates a recommendation
• "may" is used to indicate that something is permitted
• "can" is used to indicate that something is possible, for example, that an organization or individual is able to do something

So "The natural-language assertion shall be a positive statement of a constraint." states that the natural language is required to be a positive statement. I think that @xatapult is saying that the requirement is both unenforceable and unnecessary. If a Schematron file contains the unrealistic and deliberately provocative <assert test="...">Grr, wrong!</assert>, how is the Schematron processor expected to recognise that the natural language is not a positive statement? If that can be recognised, does that make the file not Schematron?

The 2016 Schematron schema for SVRL includes:

<!-- Catch-all rule-->
<sch:rule context=”*”>
  <sch:report test=”true()”> An unknown <sch:name/> element has been used.
  </sch:report>
</sch:rule>

That seems fairly neutral to me, on a par with This UUID is not unique. A more positive statement would be something like, Only SVRL elements should be used: <sch:name/> is not an SVRL element. If An unknown <sch:name/> element has been used. can be judged as insufficiently positive, does that invalidate the SVRL Schematron schema?

from schematron-enhancement-proposals.

I think that changing "shall" to "should" and providing a rationale

I need to re-acquaint myself with the ISO ordinances on terminology (they were updated after the 2016 edition of Schematron), but was under the impression that "should" in normative text was frowned upon. If not, that could also be an option.

did you mean adding this to ISO/IEC 19757, or specifically to part 3 only?

Did you have any thoughts on this, @rjelliffe ?

I want to add that our project here is to clarify and enhance the Schematron standard. I know it can be an emotive topic, but let's please all try to keep the tone of our exchanges civil and respectful. Thanks.

from schematron-enhancement-proposals.

from schematron-enhancement-proposals.

from schematron-enhancement-proposals.

(Off-topic, should we also have a better shorthand for cardinality of patterns, e.g

< sch:pattern ... expect="2"...

A new idea floated at the end of a comment on something different could easily be lost. If you think that this is worth pursuing, you could start a new issue for it or a new discussion (which is really just an issue with a less serious sounding category name, since one can be converted into the other).

from schematron-enhancement-proposals.

If a Schematron file contains ... Grr,
wrong!, how is the Schematron processor expected to
recognise that the natural language is not a positive statement?
If that can be recognised, does that make the file not
Schematron?

There has never been a requirement in ISO Specifications that only
mechanically-testable conformance requitements are allowed, has there?
(Indeed, I think no standard for software engineering can be complete
mechanically testable.)

I frequently refer to the Matterhorn Protocol, which is a checklist of ways that a PDF/UA document can be wrong. It has checks that are meant to be done by humans, even though various conformance-checking products try to automate the human checks, with mixed success.

But should a person receiving a Schematron schema have to review every statement? Should they reject a Schematron if they find any statement that is not sufficiently positive or negative?

The 2016 Schematron schema for SVRL includes:

<sch:rule context=”*”>
<sch:report test=”true()”> An unknown sch:name/ element has been used.
</sch:report>
</sch:rule>

That seems fairly neutral to me, on a par with This UUID is not unique.

The Schematron standard's conformance requirements for assertion text and
for report text are different: sch:report is looser already, IIRC, because
it is not really "schematic".

Quoting an sch:report was my error, sorry. The sch:assert that do not contain "should" were impenetrable to me, so I ended up focussing on the text and not the element when finding something to quote.

Consider https://github.com/Schematron/schema/blob/655a641bb8fe21ec4fa7b1a82498c43bc70a3bf0/svrl.sch#L53-L55:

 <sch:rule context="svrl:schematron-output"> 
     <sch:assert test="not(../*)"> The <sch:name/> element is the root element. 
     </sch:assert> 

Yes, The <sch:name/> element is the root element. is a positive statement, except that you should only see it when the statement is not true though it has no hint that it's then not true (confusing!), except that, as written, you see it for every sch:schematron-output (doubly confusing!) because the test asserts that the context element should not exist.

...

And schema validity is difference from schema conformance, in any case.
Schema validity is checked against the schemas for Schematron; then there
is "correct schema", which IIRC adds conformance to the relevant QLB, then
there is general comforming, which is that your schema and application
follows all the normative clauses of the standard.

Which is where this issue started, that the normative requirement for a positive or negative statement is overreach by the standard, restrictive, and easily ignored in practice.

The <sch:name/> element is the root element. is conforming Schematron, but it's still not good Schematron, IMO.

from schematron-enhancement-proposals.

from schematron-enhancement-proposals.

About that example: By choosing to use sch:assert for a report, they are
committing tag abuse, they then have to put in a convoluted Xpath, and then
make text that does not impose any actual schema statement. Then they
complain none of it makes sense, as if the fault is the Standard's when
THEY chose to use assert in that bogus way.

If you mean this:

<sch:assert test="not(../*)">
The <sch:name/> element is the root element.
</sch:assert>

it's also in Schematron 2006.

from schematron-enhancement-proposals.