Just for a change, here's a technical query. The TEI Enrich ODD (part of the Exemplars suite) is riddled with things like this: <attList> <attDef ident="columns" mode="change" usage="req"> <defaultVal>1</defaultVal> </attDef> </attList> which are now generating error messages from Schematron like this E [ISO Schematron] It does not make sense to make "1" the default value of @columns, because that attribute is required. Well, Mr Smartypants Schematron, it may not make sense to you, but it did to the folks who defined this ODD, and making their ODD invalid is not going to win you any friends. Could we at least change this to a warning, so that the P5 test suite can run to completion?
P5 Test works on my Jinks server - 0 errors, 0 warnings. Seems fine on the Oxford Jinks too. Where are you seeing these errors? Cheers, Martin On 15-08-04 12:45 PM, Lou Burnard wrote:
Just for a change, here's a technical query.
The TEI Enrich ODD (part of the Exemplars suite) is riddled with things like this:
<attList> <attDef ident="columns" mode="change" usage="req"> <defaultVal>1</defaultVal> </attDef> </attList>
which are now generating error messages from Schematron like this
E [ISO Schematron] It does not make sense to make "1" the default value of @columns, because that attribute is required.
Well, Mr Smartypants Schematron, it may not make sense to you, but it did to the folks who defined this ODD, and making their ODD invalid is not going to win you any friends. Could we at least change this to a warning, so that the P5 test suite can run to completion?
I'm testing the P5-Pure branch; sorry, I didn't make that clear. On 04/08/15 20:56, Martin Holmes wrote:
P5 Test works on my Jinks server - 0 errors, 0 warnings. Seems fine on the Oxford Jinks too. Where are you seeing these errors?
Cheers, Martin
On 15-08-04 12:45 PM, Lou Burnard wrote:
Just for a change, here's a technical query.
The TEI Enrich ODD (part of the Exemplars suite) is riddled with things like this:
<attList> <attDef ident="columns" mode="change" usage="req"> <defaultVal>1</defaultVal> </attDef> </attList>
which are now generating error messages from Schematron like this
E [ISO Schematron] It does not make sense to make "1" the default value of @columns, because that attribute is required.
Well, Mr Smartypants Schematron, it may not make sense to you, but it did to the folks who defined this ODD, and making their ODD invalid is not going to win you any friends. Could we at least change this to a warning, so that the P5 test suite can run to completion?
Inasmuch as there is such a thing as a "warning" in Schematron, we can certainly change the constraint (to use flag="warning"). But how on earth does it make sense to specify a default value (i.e., the value to assume when the attribute is not there) on a required attribute (i.e., one that will always be there)?
Well, Mr Smartypants Schematron, it may not make sense to you, but it did to the folks who defined this ODD, and making their ODD invalid is not going to win you any friends. Could we at least change this to a warning, so that the P5 test suite can run to completion?
I think their thinking was that if the attribute is not supplied, it should be assumed to take the default value, but that if the default value was not appropriate then an attribute must be supplied. Muddled, I agree, but that's not really the point here. Making it generate a warning rather than an error would be highly desirable. On 04/08/15 21:05, Syd Bauman wrote:
Inasmuch as there is such a thing as a "warning" in Schematron, we can certainly change the constraint (to use flag="warning"). But how on earth does it make sense to specify a default value (i.e., the value to assume when the attribute is not there) on a required attribute (i.e., one that will always be there)?
Well, Mr Smartypants Schematron, it may not make sense to you, but it did to the folks who defined this ODD, and making their ODD invalid is not going to win you any friends. Could we at least change this to a warning, so that the P5 test suite can run to completion?
We are the maintainers of the ENRICH schema, surely? Otherwise it shouldn't be in our Exemplars at all. So I would vote for fixing bad decisions in their ODD, or alternatively giving their ODD back to them for maintenance. I don't believe we should change our sensible schematron rules in order to grandfather someone else's bad decision. Cheers, Martin On 15-08-04 01:14 PM, Lou Burnard wrote:
I think their thinking was that if the attribute is not supplied, it should be assumed to take the default value, but that if the default value was not appropriate then an attribute must be supplied. Muddled, I agree, but that's not really the point here. Making it generate a warning rather than an error would be highly desirable.
On 04/08/15 21:05, Syd Bauman wrote:
Inasmuch as there is such a thing as a "warning" in Schematron, we can certainly change the constraint (to use flag="warning"). But how on earth does it make sense to specify a default value (i.e., the value to assume when the attribute is not there) on a required attribute (i.e., one that will always be there)?
Well, Mr Smartypants Schematron, it may not make sense to you, but it did to the folks who defined this ODD, and making their ODD invalid is not going to win you any friends. Could we at least change this to a warning, so that the P5 test suite can run to completion?
Well, OK, but in that case, the exemplar text needs some attention as well. For example, it currently includes a paragraph <p>Note that if (as in the last example above) no value is given for the <att>columns</att> attribute, the assumption is that there is a single column of writing on each page. The preceding example has been changed to specify a value for the @columns attribute, so that the comment quoted above is doubly confusing. I guess this is a corrigible error, so I'll corridge it. On 04/08/15 22:11, Martin Holmes wrote:
We are the maintainers of the ENRICH schema, surely? Otherwise it shouldn't be in our Exemplars at all. So I would vote for fixing bad decisions in their ODD, or alternatively giving their ODD back to them for maintenance. I don't believe we should change our sensible schematron rules in order to grandfather someone else's bad decision.
Cheers, Martin
On 15-08-04 01:14 PM, Lou Burnard wrote:
I think their thinking was that if the attribute is not supplied, it should be assumed to take the default value, but that if the default value was not appropriate then an attribute must be supplied. Muddled, I agree, but that's not really the point here. Making it generate a warning rather than an error would be highly desirable.
On 04/08/15 21:05, Syd Bauman wrote:
Inasmuch as there is such a thing as a "warning" in Schematron, we can certainly change the constraint (to use flag="warning"). But how on earth does it make sense to specify a default value (i.e., the value to assume when the attribute is not there) on a required attribute (i.e., one that will always be there)?
Well, Mr Smartypants Schematron, it may not make sense to you, but it did to the folks who defined this ODD, and making their ODD invalid is not going to win you any friends. Could we at least change this to a warning, so that the P5 test suite can run to completion?
1) Turns out this error exists because the changes made to the P5 trunk/ have (apparently) not been folded back into the P5-Pure/ branch for awhile. I changed tei_enrich.odd removing the <defaultVal> in question on 2015-06-25. 2) But if their thinking was "if the attribute is not supplied, it should be assumed to take the default value", it is faulty thinking. If the attribute is not supplied, the user gets a validation error message because a required attribute was not supplied.
I think their thinking was that if the attribute is not supplied, it should be assumed to take the default value, but that if the default value was not appropriate then an attribute must be supplied. Muddled, I agree, but that's not really the point here. Making it generate a warning rather than an error would be highly desirable.
On 04/08/15 22:33, Syd Bauman wrote:
1) Turns out this error exists because the changes made to the P5 trunk/ have (apparently) not been folded back into the P5-Pure/ branch for awhile. I changed tei_enrich.odd removing the <defaultVal> in question on 2015-06-25.
Ah, good. That's a very satisfactory explanation, which incidently reveals my total ignorance as to how exactly I should be "folding back" changes from the P5 trunk into the P5-Pure branch. I'll try to find out, and stop wingeing.
2) But if their thinking was "if the attribute is not supplied, it should be assumed to take the default value", it is faulty thinking. If the attribute is not supplied, the user gets a validation error message because a required attribute was not supplied.
I am not sure that this is in fact what happens. I think that in a DTD environment at least the default value is, as it were, present if the user does not supply it, and that hence the "required attribute" constraint is satisfied. But if we've decided to remove all these default values anyway and just make the attribute mandatory, the question is purely academic. I note (rather late) that another way of resolving it might have been to relax the "required value" constraint. The reason for specifying defaults is usually that the default value is so bleeding obvious it seems a pain to require it, e.g. @columns="1".
participants (3)
-
Lou Burnard -
Martin Holmes -
Syd Bauman