schematron and conformance

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

schematron and conformance

Lou Burnard-6
When I define my own Schematron constraints and add them into an ODD,
their effect is always to reduce  the set of documents which will be
considered valid, by comparison with the set that might be considered
valid by TEI All, or by a  version of my ODD without those constraints.
Hence I infer that schematron constraints are always going to be
restrictions rather than extensions of an existing schema, which means
(I think) that adding them has no effect on the TEI Conformance of my
ODD or the documents it validates. Good.

But what about the constraints which the TEI itself defines ? If a
document is valid against TEI All but fails some TEI-defined schematron
constraint is it no longer TEI conformant? The current definition (in
chap 23 of the Glines) says nothing on the topic. You could argue that
the object of most (or all?)  TEI-defined schematron constraints is to
test some semantic constraint otherwise expressed only loosely in the
prose, and conformance with the TEI semantic model is also a requirement
for conformance, so a document which fails the schematron test is ipso
facto non conformant. You could argue that validation with schematron is
an optional additional extra which shouldn't be required of all TEI
users, since not all validating software supports it.

Just wondering if there are any strong views out there ...
Reply | Threaded
Open this post in threaded view
|

Re: schematron and conformance

Syd Bauman-10
Overall true, I think. But of course you can easily tie yourself in
knots with discrepancies between the set of documents permitted by
the RELAX NG portion of your ODD and the Schematron portion thereof.

    <sch:report test="/tei:TEI/tei:teiHeader">Here at the weBbad
        project, we do not believe in metadata, and thus
        do not allow use of the <gi>teiHeader</gi>
        element.</sch:report>

But keep in mind that some Schematron constraints are explicitly
role="nonfatal". These should not, IMHO, be violations of TEI
conformance, whether or not the others are.

> When I define my own Schematron constraints and add them into an
> ODD, their effect is always to reduce the set of documents which
> will be considered valid, by comparison with the set that might be
> considered valid by TEI All, or by a version of my ODD without
> those constraints. Hence I infer that schematron constraints are
> always going to be restrictions rather than extensions of an
> existing schema, which means (I think) that adding them has no
> effect on the TEI Conformance of my ODD or the documents it
> validates. Good.
>
> But what about the constraints which the TEI itself defines ? If a
> document is valid against TEI All but fails some TEI-defined
> schematron constraint is it no longer TEI conformant? The current
> definition (in chap 23 of the Glines) says nothing on the topic.
> You could argue that the object of most (or all?) TEI-defined
> schematron constraints is to test some semantic constraint
> otherwise expressed only loosely in the prose, and conformance with
> the TEI semantic model is also a requirement for conformance, so a
> document which fails the schematron test is ipso facto non
> conformant. You could argue that validation with schematron is an
> optional additional extra which shouldn't be required of all TEI
> users, since not all validating software supports it.
>
> Just wondering if there are any strong views out there ...
Reply | Threaded
Open this post in threaded view
|

Re: schematron and conformance

Martin Holmes
I actually disagree with Syd here (which almost never happens). For some
years we've been treating Schematron constraints as an integral part of
the TEI schemas, and we haven't to my knowledge ever thought of them
constraints as inferior or optional. If you ask for a new TEI P5 "all"
document in Oxygen, you get two xml-models:

<?xml-model
href="http://www.tei-c.org/release/xml/tei/custom/schema/relaxng/tei_all.rng"
type="application/xml" schematypens="http://relaxng.org/ns/structure/1.0"?>
<?xml-model
href="http://www.tei-c.org/release/xml/tei/custom/schema/relaxng/tei_all.rng"
type="application/xml"
        schematypens="http://purl.oclc.org/dsdl/schematron"?>

explicitly referencing the Schematron alongside the RNG.

I do think we need to make more noise about this, and make it very clear
that validation should always include the Schematron rules as well as
the RelaxNG schemas. But if Syd is right, and Schematron is [in future
defined as] merely nice-to-have, then I think there are a lot of
constraints that have been defined in Schematron up to now that will
need to be looked at more closely to see if they can be reimplemented in
ODD in such a way that schemas can include them.

Cheers,
Martin

On 2017-03-26 12:22 PM, Syd Bauman wrote:

> Overall true, I think. But of course you can easily tie yourself in
> knots with discrepancies between the set of documents permitted by
> the RELAX NG portion of your ODD and the Schematron portion thereof.
>
>     <sch:report test="/tei:TEI/tei:teiHeader">Here at the weBbad
>         project, we do not believe in metadata, and thus
>         do not allow use of the <gi>teiHeader</gi>
>         element.</sch:report>
>
> But keep in mind that some Schematron constraints are explicitly
> role="nonfatal". These should not, IMHO, be violations of TEI
> conformance, whether or not the others are.
>
>> When I define my own Schematron constraints and add them into an
>> ODD, their effect is always to reduce the set of documents which
>> will be considered valid, by comparison with the set that might be
>> considered valid by TEI All, or by a version of my ODD without
>> those constraints. Hence I infer that schematron constraints are
>> always going to be restrictions rather than extensions of an
>> existing schema, which means (I think) that adding them has no
>> effect on the TEI Conformance of my ODD or the documents it
>> validates. Good.
>>
>> But what about the constraints which the TEI itself defines ? If a
>> document is valid against TEI All but fails some TEI-defined
>> schematron constraint is it no longer TEI conformant? The current
>> definition (in chap 23 of the Glines) says nothing on the topic.
>> You could argue that the object of most (or all?) TEI-defined
>> schematron constraints is to test some semantic constraint
>> otherwise expressed only loosely in the prose, and conformance with
>> the TEI semantic model is also a requirement for conformance, so a
>> document which fails the schematron test is ipso facto non
>> conformant. You could argue that validation with schematron is an
>> optional additional extra which shouldn't be required of all TEI
>> users, since not all validating software supports it.
>>
>> Just wondering if there are any strong views out there ...
Reply | Threaded
Open this post in threaded view
|

Re: schematron and conformance

Birnbaum, David J
Dear TEI-L,

I understand that there are historical and technical reasons that we may
regard Schematron constraints as something different from the sorts of
rules that we might express in DTD or Relax NG or W3Schema (by way of
ODD). But from the perspective of the human, should it matter whether a
particular constraint is implemented in one way, rather than another? As a
human thinking about how I might enhance, constrain, and otherwise adapt
the TEI guidelines to match my project requirements, I might think that
³in a particular environment my project requires tei:X, permits tei:Y, and
prohibits tei:Z². Should it matter, with respect to TEI conformance,
whether I enforce such a project-specific modification with Schematron or
without Schematron? This isn¹t meant as a rhetorical question, so I¹m
equally happy with responses that skew toward ³yes² and those that skew
toward ³no²; I guess I¹m asking whether conformance is just a matter of
what we require, permit, and prohibit, or also of the technology we use to
do that. And, for what it¹s worth, I almost never disagree with either Syd
or Martin.

Best,

David

On 2017-26-03, 3:38 PM, "TEI (Text Encoding Initiative) public discussion
list on behalf of Martin Holmes" <[hidden email] on behalf of
[hidden email]> wrote:

>I actually disagree with Syd here (which almost never happens). For some
>years we've been treating Schematron constraints as an integral part of
>the TEI schemas, and we haven't to my knowledge ever thought of them
>constraints as inferior or optional. If you ask for a new TEI P5 "all"
>document in Oxygen, you get two xml-models:
>
><?xml-model
>href="https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.
>tei-c.org%2Frelease%2Fxml%2Ftei%2Fcustom%2Fschema%2Frelaxng%2Ftei_all.rng&
>data=01%7C01%7Cdjbpitt%40PITT.EDU%7Cea218d4ea5394ce8b2f208d4747fba50%7C9ef
>9f489e0a04eeb87cc3a526112fd0d%7C1&sdata=5V1xWfu6a7BMBSelWbU8CJjRWwgUNXQoVg
>1EtaMhM%2Fc%3D&reserved=0"
>type="application/xml"
>schematypens="<a href="https://na01.safelinks.protection.outlook.com/?url=http%3A%2">https://na01.safelinks.protection.outlook.com/?url=http%3A%2
>F%2Frelaxng.org%2Fns%2Fstructure%2F1.0&data=01%7C01%7Cdjbpitt%40PITT.EDU%7
>Cea218d4ea5394ce8b2f208d4747fba50%7C9ef9f489e0a04eeb87cc3a526112fd0d%7C1&s
>data=YW%2FW9oJHXaOGsXW9%2FCBC5zjqCwKdbSbbQZq9UGTEjzE%3D&reserved=0"?>
><?xml-model
>href="https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.
>tei-c.org%2Frelease%2Fxml%2Ftei%2Fcustom%2Fschema%2Frelaxng%2Ftei_all.rng&
>data=01%7C01%7Cdjbpitt%40PITT.EDU%7Cea218d4ea5394ce8b2f208d4747fba50%7C9ef
>9f489e0a04eeb87cc3a526112fd0d%7C1&sdata=5V1xWfu6a7BMBSelWbU8CJjRWwgUNXQoVg
>1EtaMhM%2Fc%3D&reserved=0"
>type="application/xml"
> schematypens="<a href="https://na01.safelinks.protection.outlook.com/?url=http%3A%">https://na01.safelinks.protection.outlook.com/?url=http%3A%
>2F%2Fpurl.oclc.org%2Fdsdl%2Fschematron&data=01%7C01%7Cdjbpitt%40PITT.EDU%7
>Cea218d4ea5394ce8b2f208d4747fba50%7C9ef9f489e0a04eeb87cc3a526112fd0d%7C1&s
>data=iYhR%2FXbFV2k4M0doIuhaO5WvLB8TsJNrITmCqyRXZRs%3D&reserved=0"?>
>
>explicitly referencing the Schematron alongside the RNG.
>
>I do think we need to make more noise about this, and make it very clear
>that validation should always include the Schematron rules as well as
>the RelaxNG schemas. But if Syd is right, and Schematron is [in future
>defined as] merely nice-to-have, then I think there are a lot of
>constraints that have been defined in Schematron up to now that will
>need to be looked at more closely to see if they can be reimplemented in
>ODD in such a way that schemas can include them.
>
>Cheers,
>Martin
>
>On 2017-03-26 12:22 PM, Syd Bauman wrote:
>> Overall true, I think. But of course you can easily tie yourself in
>> knots with discrepancies between the set of documents permitted by
>> the RELAX NG portion of your ODD and the Schematron portion thereof.
>>
>>     <sch:report test="/tei:TEI/tei:teiHeader">Here at the weBbad
>>         project, we do not believe in metadata, and thus
>>         do not allow use of the <gi>teiHeader</gi>
>>         element.</sch:report>
>>
>> But keep in mind that some Schematron constraints are explicitly
>> role="nonfatal". These should not, IMHO, be violations of TEI
>> conformance, whether or not the others are.
>>
>>> When I define my own Schematron constraints and add them into an
>>> ODD, their effect is always to reduce the set of documents which
>>> will be considered valid, by comparison with the set that might be
>>> considered valid by TEI All, or by a version of my ODD without
>>> those constraints. Hence I infer that schematron constraints are
>>> always going to be restrictions rather than extensions of an
>>> existing schema, which means (I think) that adding them has no
>>> effect on the TEI Conformance of my ODD or the documents it
>>> validates. Good.
>>>
>>> But what about the constraints which the TEI itself defines ? If a
>>> document is valid against TEI All but fails some TEI-defined
>>> schematron constraint is it no longer TEI conformant? The current
>>> definition (in chap 23 of the Glines) says nothing on the topic.
>>> You could argue that the object of most (or all?) TEI-defined
>>> schematron constraints is to test some semantic constraint
>>> otherwise expressed only loosely in the prose, and conformance with
>>> the TEI semantic model is also a requirement for conformance, so a
>>> document which fails the schematron test is ipso facto non
>>> conformant. You could argue that validation with schematron is an
>>> optional additional extra which shouldn't be required of all TEI
>>> users, since not all validating software supports it.
>>>
>>> Just wondering if there are any strong views out there ...
Reply | Threaded
Open this post in threaded view
|

Re: schematron and conformance

Syd Bauman-10
In reply to this post by Martin Holmes
Hmmm ... I wonder if Martin & I really disagree, or I just wasn't
clear enough. I tried to remain neutral on the question as to whether
or not passing Schematron constraints (other than those with an @role
of "nonfatal" or "warning") is part of conformance.

I was neutral not because I don't have an opinion on the subject,
just because it wasn't the point of that particular post.

My opinion is:

 * There is no difference whether an *error* is flagged by RELAX NG,
   Schematron, or something else. (Or is not flagged at all, as would
   happen often if you were using DTDs.)

 * We can (and do) use Schematron to deliver messages that are not
   errors. Those should not be considered when thinking about
   conformance.

 * There are a few places where TEI flags a problem and reports it as
   an error where I think it maybe should be changed to "nonfatal"
   (or "warning" or "warn" or whatever), and thus not be considered
   when thinking about conformance.


> I actually disagree with Syd here (which almost never happens). For some
> years we've been treating Schematron constraints as an integral part of
> the TEI schemas, and we haven't to my knowledge ever thought of them
> constraints as inferior or optional. If you ask for a new TEI P5 "all"
> document in Oxygen, you get two xml-models:
>
> <?xml-model
> href="http://www.tei-c.org/release/xml/tei/custom/schema/relaxng/tei_all.rng"
> type="application/xml" schematypens="http://relaxng.org/ns/structure/1.0"?>
> <?xml-model
> href="http://www.tei-c.org/release/xml/tei/custom/schema/relaxng/tei_all.rng"
> type="application/xml"
>       schematypens="http://purl.oclc.org/dsdl/schematron"?>
>
> explicitly referencing the Schematron alongside the RNG.
>
> I do think we need to make more noise about this, and make it very clear
> that validation should always include the Schematron rules as well as
> the RelaxNG schemas. But if Syd is right, and Schematron is [in future
> defined as] merely nice-to-have, then I think there are a lot of
> constraints that have been defined in Schematron up to now that will
> need to be looked at more closely to see if they can be reimplemented in
> ODD in such a way that schemas can include them.
Reply | Threaded
Open this post in threaded view
|

Re: schematron and conformance

Piotr Banski
In reply to this post by Lou Burnard-6
Hi Lou,

I think that, whether a strong one or not, there is a "technological
view" here, namely I recall hitting Schematron errors in the TEI/P5
build process (the full one including tests, with `make`). So to the
extent that the test part of the process is in some way integral to the
processing of TEI sources, it looks like Schematron is considered part
of the validity requirement.

Best,

   P.

On 26/03/17 21:06, Lou Burnard wrote:

> When I define my own Schematron constraints and add them into an ODD,
> their effect is always to reduce  the set of documents which will be
> considered valid, by comparison with the set that might be considered
> valid by TEI All, or by a  version of my ODD without those constraints.
> Hence I infer that schematron constraints are always going to be
> restrictions rather than extensions of an existing schema, which means
> (I think) that adding them has no effect on the TEI Conformance of my
> ODD or the documents it validates. Good.
>
> But what about the constraints which the TEI itself defines ? If a
> document is valid against TEI All but fails some TEI-defined schematron
> constraint is it no longer TEI conformant? The current definition (in
> chap 23 of the Glines) says nothing on the topic. You could argue that
> the object of most (or all?)  TEI-defined schematron constraints is to
> test some semantic constraint otherwise expressed only loosely in the
> prose, and conformance with the TEI semantic model is also a requirement
> for conformance, so a document which fails the schematron test is ipso
> facto non conformant. You could argue that validation with schematron is
> an optional additional extra which shouldn't be required of all TEI
> users, since not all validating software supports it.
>
> Just wondering if there are any strong views out there ...
>
Reply | Threaded
Open this post in threaded view
|

Re: schematron and conformance

Piotr Banski
In reply to this post by Syd Bauman-10
Hi Syd,

But is this a valid argument? You're presenting a rogue constraint as
opposed to one blessed by the Technical Council by inclusion in the TEI
source. Rogues can do krazy fings, I mean, just look at me...

Best,

   P.

On 26/03/17 21:22, Syd Bauman wrote:

> Overall true, I think. But of course you can easily tie yourself in
> knots with discrepancies between the set of documents permitted by
> the RELAX NG portion of your ODD and the Schematron portion thereof.
>
>     <sch:report test="/tei:TEI/tei:teiHeader">Here at the weBbad
>         project, we do not believe in metadata, and thus
>         do not allow use of the <gi>teiHeader</gi>
>         element.</sch:report>
>
> But keep in mind that some Schematron constraints are explicitly
> role="nonfatal". These should not, IMHO, be violations of TEI
> conformance, whether or not the others are.
>
>> When I define my own Schematron constraints and add them into an
>> ODD, their effect is always to reduce the set of documents which
>> will be considered valid, by comparison with the set that might be
>> considered valid by TEI All, or by a version of my ODD without
>> those constraints. Hence I infer that schematron constraints are
>> always going to be restrictions rather than extensions of an
>> existing schema, which means (I think) that adding them has no
>> effect on the TEI Conformance of my ODD or the documents it
>> validates. Good.
>>
>> But what about the constraints which the TEI itself defines ? If a
>> document is valid against TEI All but fails some TEI-defined
>> schematron constraint is it no longer TEI conformant? The current
>> definition (in chap 23 of the Glines) says nothing on the topic.
>> You could argue that the object of most (or all?) TEI-defined
>> schematron constraints is to test some semantic constraint
>> otherwise expressed only loosely in the prose, and conformance with
>> the TEI semantic model is also a requirement for conformance, so a
>> document which fails the schematron test is ipso facto non
>> conformant. You could argue that validation with schematron is an
>> optional additional extra which shouldn't be required of all TEI
>> users, since not all validating software supports it.
>>
>> Just wondering if there are any strong views out there ...
>
Reply | Threaded
Open this post in threaded view
|

Re: schematron and conformance

Martin Holmes
In reply to this post by Syd Bauman-10
Sorry if I misunderstood you Syd. There are currently 74 Schematron
assertions and reports in the P5 source, of which only 9 have
@role='nonfatal'; 4 of those relate to deprecations, so they are
certainly advisory, but others are rather strange:

<constraintSpec ident="att-datable-w3c-when" scheme="isoschematron">
     <constraint>
       <sch:rule context="tei:*[@when]">
         <sch:report test="@notBefore|@notAfter|@from|@to"
role="nonfatal">The @when attribute cannot be used with any other
att.datable.w3c attributes.</sch:report>
       </sch:rule>
     </constraint>
   </constraintSpec>

The report says "cannot be used", which is pretty categorical; I don't
see how this could be both accurate ("cannot") and nonfatal/advisory.
All five of the "nonfatal" rules which are not related to deprecation
explicitly use the word "cannot". This just seems wrong to me. If
they're really advisory, they should use different terminology, surely.

Cheers,
Martin

On 2017-03-26 03:36 PM, Syd Bauman wrote:

> Hmmm ... I wonder if Martin & I really disagree, or I just wasn't
> clear enough. I tried to remain neutral on the question as to whether
> or not passing Schematron constraints (other than those with an @role
> of "nonfatal" or "warning") is part of conformance.
>
> I was neutral not because I don't have an opinion on the subject,
> just because it wasn't the point of that particular post.
>
> My opinion is:
>
>  * There is no difference whether an *error* is flagged by RELAX NG,
>    Schematron, or something else. (Or is not flagged at all, as would
>    happen often if you were using DTDs.)
>
>  * We can (and do) use Schematron to deliver messages that are not
>    errors. Those should not be considered when thinking about
>    conformance.
>
>  * There are a few places where TEI flags a problem and reports it as
>    an error where I think it maybe should be changed to "nonfatal"
>    (or "warning" or "warn" or whatever), and thus not be considered
>    when thinking about conformance.
>
>
>> I actually disagree with Syd here (which almost never happens). For some
>> years we've been treating Schematron constraints as an integral part of
>> the TEI schemas, and we haven't to my knowledge ever thought of them
>> constraints as inferior or optional. If you ask for a new TEI P5 "all"
>> document in Oxygen, you get two xml-models:
>>
>> <?xml-model
>> href="http://www.tei-c.org/release/xml/tei/custom/schema/relaxng/tei_all.rng"
>> type="application/xml" schematypens="http://relaxng.org/ns/structure/1.0"?>
>> <?xml-model
>> href="http://www.tei-c.org/release/xml/tei/custom/schema/relaxng/tei_all.rng"
>> type="application/xml"
>>       schematypens="http://purl.oclc.org/dsdl/schematron"?>
>>
>> explicitly referencing the Schematron alongside the RNG.
>>
>> I do think we need to make more noise about this, and make it very clear
>> that validation should always include the Schematron rules as well as
>> the RelaxNG schemas. But if Syd is right, and Schematron is [in future
>> defined as] merely nice-to-have, then I think there are a lot of
>> constraints that have been defined in Schematron up to now that will
>> need to be looked at more closely to see if they can be reimplemented in
>> ODD in such a way that schemas can include them.
Reply | Threaded
Open this post in threaded view
|

Re: schematron and conformance

Lou Burnard-6
In this particular case, I think that "cannot" is misleading, and should
be replaced by "should not". You *can* use @when together with (say)
@notAfter if you don't invoke schematron validation. Council decided
that this combination of attributes didn't make sense, and therefore it
would be helpful to deprecate the practice. But you cannot actually make
deprecated behaviour impossible, which is what "cannot" means to me.

My question remains unanswered however: is a TEI document which indulges
in deprecated (in another context Michael has suggested the term
"deviant") behaviour ipso fact non TEI conformant?




  On 27/03/17 02:59, Martin Holmes wrote:

> Sorry if I misunderstood you Syd. There are currently 74 Schematron
> assertions and reports in the P5 source, of which only 9 have
> @role='nonfatal'; 4 of those relate to deprecations, so they are
> certainly advisory, but others are rather strange:
>
> <constraintSpec ident="att-datable-w3c-when" scheme="isoschematron">
>     <constraint>
>       <sch:rule context="tei:*[@when]">
>         <sch:report test="@notBefore|@notAfter|@from|@to"
> role="nonfatal">The @when attribute cannot be used with any other
> att.datable.w3c attributes.</sch:report>
>       </sch:rule>
>     </constraint>
>   </constraintSpec>
>
> The report says "cannot be used", which is pretty categorical; I don't
> see how this could be both accurate ("cannot") and nonfatal/advisory.
> All five of the "nonfatal" rules which are not related to deprecation
> explicitly use the word "cannot". This just seems wrong to me. If
> they're really advisory, they should use different terminology, surely.
>
> Cheers,
> Martin
>
> On 2017-03-26 03:36 PM, Syd Bauman wrote:
>> Hmmm ... I wonder if Martin & I really disagree, or I just wasn't
>> clear enough. I tried to remain neutral on the question as to whether
>> or not passing Schematron constraints (other than those with an @role
>> of "nonfatal" or "warning") is part of conformance.
>>
>> I was neutral not because I don't have an opinion on the subject,
>> just because it wasn't the point of that particular post.
>>
>> My opinion is:
>>
>>  * There is no difference whether an *error* is flagged by RELAX NG,
>>    Schematron, or something else. (Or is not flagged at all, as would
>>    happen often if you were using DTDs.)
>>
>>  * We can (and do) use Schematron to deliver messages that are not
>>    errors. Those should not be considered when thinking about
>>    conformance.
>>
>>  * There are a few places where TEI flags a problem and reports it as
>>    an error where I think it maybe should be changed to "nonfatal"
>>    (or "warning" or "warn" or whatever), and thus not be considered
>>    when thinking about conformance.
>>
>>
>>> I actually disagree with Syd here (which almost never happens). For
>>> some
>>> years we've been treating Schematron constraints as an integral part of
>>> the TEI schemas, and we haven't to my knowledge ever thought of them
>>> constraints as inferior or optional. If you ask for a new TEI P5 "all"
>>> document in Oxygen, you get two xml-models:
>>>
>>> <?xml-model
>>> href="http://www.tei-c.org/release/xml/tei/custom/schema/relaxng/tei_all.rng"
>>>
>>> type="application/xml"
>>> schematypens="http://relaxng.org/ns/structure/1.0"?>
>>> <?xml-model
>>> href="http://www.tei-c.org/release/xml/tei/custom/schema/relaxng/tei_all.rng"
>>>
>>> type="application/xml"
>>>       schematypens="http://purl.oclc.org/dsdl/schematron"?>
>>>
>>> explicitly referencing the Schematron alongside the RNG.
>>>
>>> I do think we need to make more noise about this, and make it very
>>> clear
>>> that validation should always include the Schematron rules as well as
>>> the RelaxNG schemas. But if Syd is right, and Schematron is [in future
>>> defined as] merely nice-to-have, then I think there are a lot of
>>> constraints that have been defined in Schematron up to now that will
>>> need to be looked at more closely to see if they can be
>>> reimplemented in
>>> ODD in such a way that schemas can include them.
Reply | Threaded
Open this post in threaded view
|

Re: schematron and conformance

Martin Holmes
Hi Lou,

> You *can* use @when together with (say) @notAfter if you don't invoke
> schematron validation.

and you *can* use <anyoldthing> inside <TEI> if you don't invoke RelaxNG
validation.

As far as I remember, the decision to express a constraint in a
Schematron rule as opposed to a construct that translates into RelaxNG
has never been made on the basis of the rule's supposed regulatory force
(for want of a better way of putting it); it's always been made on the
basis of practicality (we can't do this [yet] in ODD/RelaxNG). Therefore
I don't believe it makes sense to say that these constraints are in any
way less significant than regular constraints, except in the case of
deprecation warnings, which are explicitly warnings rather than errors.

Cheers,
Martin


On 2017-03-27 04:13 AM, Lou Burnard wrote:

> In this particular case, I think that "cannot" is misleading, and
> should be replaced by "should not". You *can* use @when together with
> (say) @notAfter if you don't invoke schematron validation. Council
> decided that this combination of attributes didn't make sense, and
> therefore it would be helpful to deprecate the practice. But you
> cannot actually make deprecated behaviour impossible, which is what
> "cannot" means to me.
>
> My question remains unanswered however: is a TEI document which
> indulges in deprecated (in another context Michael has suggested the
> term "deviant") behaviour ipso fact non TEI conformant?
>
>
>
>
> On 27/03/17 02:59, Martin Holmes wrote:
>> Sorry if I misunderstood you Syd. There are currently 74
>> Schematron assertions and reports in the P5 source, of which only 9
>> have @role='nonfatal'; 4 of those relate to deprecations, so they
>> are certainly advisory, but others are rather strange:
>>
>> <constraintSpec ident="att-datable-w3c-when"
>> scheme="isoschematron"> <constraint> <sch:rule
>> context="tei:*[@when]"> <sch:report
>> test="@notBefore|@notAfter|@from|@to" role="nonfatal">The @when
>> attribute cannot be used with any other att.datable.w3c
>> attributes.</sch:report> </sch:rule> </constraint>
>> </constraintSpec>
>>
>> The report says "cannot be used", which is pretty categorical; I
>> don't see how this could be both accurate ("cannot") and
>> nonfatal/advisory. All five of the "nonfatal" rules which are not
>> related to deprecation explicitly use the word "cannot". This just
>> seems wrong to me. If they're really advisory, they should use
>> different terminology, surely.
>>
>> Cheers, Martin
>>
>> On 2017-03-26 03:36 PM, Syd Bauman wrote:
>>> Hmmm ... I wonder if Martin & I really disagree, or I just
>>> wasn't clear enough. I tried to remain neutral on the question as
>>> to whether or not passing Schematron constraints (other than
>>> those with an @role of "nonfatal" or "warning") is part of
>>> conformance.
>>>
>>> I was neutral not because I don't have an opinion on the
>>> subject, just because it wasn't the point of that particular
>>> post.
>>>
>>> My opinion is:
>>>
>>> * There is no difference whether an *error* is flagged by RELAX
>>> NG, Schematron, or something else. (Or is not flagged at all, as
>>> would happen often if you were using DTDs.)
>>>
>>> * We can (and do) use Schematron to deliver messages that are
>>> not errors. Those should not be considered when thinking about
>>> conformance.
>>>
>>> * There are a few places where TEI flags a problem and reports it
>>> as an error where I think it maybe should be changed to
>>> "nonfatal" (or "warning" or "warn" or whatever), and thus not be
>>> considered when thinking about conformance.
>>>
>>>
>>>> I actually disagree with Syd here (which almost never happens).
>>>> For some years we've been treating Schematron constraints as an
>>>> integral part of the TEI schemas, and we haven't to my
>>>> knowledge ever thought of them constraints as inferior or
>>>> optional. If you ask for a new TEI P5 "all" document in Oxygen,
>>>> you get two xml-models:
>>>>
>>>> <?xml-model
>>>> href="http://www.tei-c.org/release/xml/tei/custom/schema/relaxng/tei_all.rng"
>>>>
>>>>
>>>>
type="application/xml"
>>>> schematypens="http://relaxng.org/ns/structure/1.0"?>
>>>> <?xml-model
>>>> href="http://www.tei-c.org/release/xml/tei/custom/schema/relaxng/tei_all.rng"
>>>>
>>>>
>>>>
type="application/xml"

>>>> schematypens="http://purl.oclc.org/dsdl/schematron"?>
>>>>
>>>> explicitly referencing the Schematron alongside the RNG.
>>>>
>>>> I do think we need to make more noise about this, and make it
>>>> very clear that validation should always include the Schematron
>>>> rules as well as the RelaxNG schemas. But if Syd is right, and
>>>> Schematron is [in future defined as] merely nice-to-have, then
>>>> I think there are a lot of constraints that have been defined
>>>> in Schematron up to now that will need to be looked at more
>>>> closely to see if they can be reimplemented in ODD in such a
>>>> way that schemas can include them.
>
>
Reply | Threaded
Open this post in threaded view
|

Re: schematron and conformance

Lou Burnard-6
On 27/03/17 13:33, Martin Holmes wrote:
> Hi Lou,
>
>> You *can* use @when together with (say) @notAfter if you don't invoke
>> schematron validation.
>
> and you *can* use <anyoldthing> inside <TEI> if you don't invoke
> RelaxNG validation.

Except that validation against a RelaxNG  schema is explicitly part of
our conformance definition, and validation against IsoSchematron isn't,
or not so far as I can see. Hence my question.


>
> As far as I remember, the decision to express a constraint in a
> Schematron rule as opposed to a construct that translates into RelaxNG
> has never been made on the basis of the rule's supposed regulatory
> force (for want of a better way of putting it); it's always been made
> on the basis of practicality (we can't do this [yet] in ODD/RelaxNG).
> Therefore I don't believe it makes sense to say that these constraints
> are in any way less significant than regular constraints, except in
> the case of deprecation warnings, which are explicitly warnings rather
> than errors.
>

OK, thanks, that's an answer to my question. I'm not sure if I entirely
agree with it -- it would enable us to side step birnbaum very easily --
but that's not relevant.
Reply | Threaded
Open this post in threaded view
|

Re: schematron and conformance

Syd Bauman-10
In reply to this post by Martin Holmes
Hi, Martin --

First, I think your main point (of "cannot" being incongruous with
role="nonfatal") is a good one, worthy of a ticket.

But keep in mind when you look for these things, though, that some
are generated at build time. So if you look in p5.xml you find only
11 @roles (9 "nonfatal", 2 "warning"). But if you look in
Exemplars/tei_all.isosch you find there are 42 @roles (15 "nonfatal",
2 "warning", and 25 "error", out of a total of 99 <assert>s and
<report>s).


> Sorry if I misunderstood you Syd. There are currently 74 Schematron
> assertions and reports in the P5 source, of which only 9 have
> @role='nonfatal'; 4 of those relate to deprecations, so they are
> certainly advisory, but others are rather strange:
>
> <constraintSpec ident="att-datable-w3c-when" scheme="isoschematron">
>      <constraint>
>        <sch:rule context="tei:*[@when]">
>          <sch:report test="@notBefore|@notAfter|@from|@to"
> role="nonfatal">The @when attribute cannot be used with any other
> att.datable.w3c attributes.</sch:report>
>        </sch:rule>
>      </constraint>
>    </constraintSpec>
>
> The report says "cannot be used", which is pretty categorical; I don't
> see how this could be both accurate ("cannot") and nonfatal/advisory.
> All five of the "nonfatal" rules which are not related to deprecation
> explicitly use the word "cannot". This just seems wrong to me. If
> they're really advisory, they should use different terminology, surely.
Reply | Threaded
Open this post in threaded view
|

Re: schematron and conformance

Syd Bauman-10
In reply to this post by Lou Burnard-6
[I realize Martin has already responded, and I think he is correct,
but there is more to say, here.]

> In this particular case, I think that "cannot" is misleading, and
> should be replaced by "should not".

I think you are right. BUT ...


> You *can* use @when together with (say) @notAfter if you don't
> invoke schematron validation.

"Cannot" does not mean that it is impossible for you to type that
combination on your keyboard. Surely "cannot" means it is impossible
for you to use that combination and remain TEI conformant, no?


> My question remains unanswered however: is a TEI document which
> indulges in deprecated (in another context Michael has suggested
> the term "deviant") behaviour ipso fact non TEI conformant?

No. IMHO having a deprecated construct in your file does not violate
conformance per se. But to understand my explanation, you will need
to keep in mind that TEI conformance is not a general-purpose
concept, but rather a concept that is expressed in relation to a
particular version. So here is a fictitious scenario. Let's say in
the future TEI Council decides to remove the <head> element from TEI
while 4.12.0 is the current version.

 * In P5 version 4.12.0 it is still valid. Use is valid and
   conformant.
 
 * In P5 versions 4.13.0 through 4.16.0 it is deprecated. Use is
   conformant but raises a warning. There is a red box and warning
   around it in the reference section of the documentation. It is no
   longer discussed as a useful method in the prose, and there are no
   examples of its use in the Guidelines.

 * In P5 version 4.17.0 it is removed. Use is invalid (i.e., raises
   an error) and non-conformant. It is not mentioned in the
   Guidelines at all (except perhaps nostalgically :-)

(BTW, I don't for a moment suggest that Council would do anything as
dumb as removing the <head> element -- besides being ridiculous, it
would violate our rules on breaking backward compatibility.)
Reply | Threaded
Open this post in threaded view
|

Re: schematron and conformance

Lou Burnard-6
On 27/03/17 14:02, Syd Bauman wrote:
> You *can* use @when together with (say) @notAfter if you don't
>> invoke schematron validation.
> "Cannot" does not mean that it is impossible for you to type that
> combination on your keyboard. Surely "cannot" means it is impossible
> for you to use that combination and remain TEI conformant, no?

Well, this is begging the question. Yes if you consider validity against
schematron constraints to be a necessary
part of TEI conformance. No if it isn't.

[snip]

> TEI conformance is not a general-purpose
> concept, but rather a concept that is expressed in relation to a
> particular version.

Yes, this is a good point, and the definition of the conformance
certainly needs to be more explicit about that,


> So here is a fictitious scenario.

This is all well and good. But am I wrong in thinking that occasionally
schematron constraints are introduced which do not cause any component
to be "deprecated" in the sense that they gain a @validUntil attribute
which sets in train the scenario you describe? Constraints which just
say "up till now the Guidelines may have permitted this because the
schema wasn't expressive enough, but it's always been wrong and now
we're going to check for it."
Reply | Threaded
Open this post in threaded view
|

Re: schematron and conformance

Syd Bauman-10
> Well, this is begging the question. Yes if you consider validity
> against schematron constraints to be a necessary part of TEI
> conformance. No if it isn't.

And I do consider validity against constraints (Schematron or
otherwise) that are errors (as opposed to just warnings) to be
a necessary part of TEI conformance.


> This is all well and good. But am I wrong in thinking that
> occasionally schematron constraints are introduced which do not
> cause any component to be "deprecated" in the sense that they gain
> a @validUntil attribute which sets in train the scenario you
> describe? Constraints which just say "up till now the Guidelines
> may have permitted this because the schema wasn't expressive
> enough, but it's always been wrong and now we're going to check for
> it."

You are (of course) completely correct. There exist quite a few such
"now we can check for it" constraints. (And there will probably be
more as time goes on.)
Reply | Threaded
Open this post in threaded view
|

Re: schematron and conformance

Lou Burnard-6
On 27/03/17 15:23, Syd Bauman wrote:
>> Well, this is begging the question. Yes if you consider validity
>> against schematron constraints to be a necessary part of TEI
>> conformance. No if it isn't.
> And I do consider validity against constraints (Schematron or
> otherwise) that are errors (as opposed to just warnings) to be
> a necessary part of TEI conformance.

OK. So now someone needs to formulate the principles by which it is
decided whether something is an error or just a warning.

>
>> This is all well and good. But am I wrong in thinking that
>> occasionally schematron constraints are introduced which do not
>> cause any component to be "deprecated" in the sense that they gain
>> a @validUntil attribute which sets in train the scenario you
>> describe? Constraints which just say "up till now the Guidelines
>> may have permitted this because the schema wasn't expressive
>> enough, but it's always been wrong and now we're going to check for
>> it."
> You are (of course) completely correct. There exist quite a few such
> "now we can check for it" constraints. (And there will probably be
> more as time goes on.)

Gulp. Sounds like a threat....
Reply | Threaded
Open this post in threaded view
|

Re: schematron and conformance

Martin Holmes
Hi all,

I've raised a ticket for this:

<https://github.com/TEIC/TEI/issues/1621>

Please chime in to correct any misunderstandings in my summary.

Cheers,
Martin

On 2017-03-27 07:26 AM, Lou Burnard wrote:

> On 27/03/17 15:23, Syd Bauman wrote:
>>> Well, this is begging the question. Yes if you consider validity
>>> against schematron constraints to be a necessary part of TEI
>>> conformance. No if it isn't.
>> And I do consider validity against constraints (Schematron or
>> otherwise) that are errors (as opposed to just warnings) to be
>> a necessary part of TEI conformance.
>
> OK. So now someone needs to formulate the principles by which it is
> decided whether something is an error or just a warning.
>
>>
>>> This is all well and good. But am I wrong in thinking that
>>> occasionally schematron constraints are introduced which do not
>>> cause any component to be "deprecated" in the sense that they gain
>>> a @validUntil attribute which sets in train the scenario you
>>> describe? Constraints which just say "up till now the Guidelines
>>> may have permitted this because the schema wasn't expressive
>>> enough, but it's always been wrong and now we're going to check for
>>> it."
>> You are (of course) completely correct. There exist quite a few such
>> "now we can check for it" constraints. (And there will probably be
>> more as time goes on.)
>
> Gulp. Sounds like a threat....