Closed proycon closed 3 years ago
From the second example:
<t>op de wyse: <t-style class="i">Pharaos VVimpelen ontdaan, en sietmen niet meer svvieren. </t-style>Oft, <t-style class="i">Nu singt, nu springt, &c.</t-style></t>
VALIDATION ERROR on full parse by library (stage 2/3), in issue92b_2.2.0.folia.xml
ParseError: FoLiA exception in handling of <div> @ line 97 (in parent <text> @ parent line 96) : [InconsistentText] Text for <Head at 140533694914624 id=_nie190nieu04_01.text.div.1.div.2.div.1.head.1 set=https://raw.githubusercontent.com/proycon/folia/master/setdefinitions/tei2folia/heads.foliaset.ttl class=h4>, is inconsistent: EXPECTED (after normalization) *****>
op de wyse: Pharaos VVimpelen ontdaan, en sietmen niet meer svvieren. Oft, Nu singt, nu springt, &c.
****> BUT FOUND (after normalization) ****>
op de wyse: Pharaos VVimpelen ontdaan, en sietmen niet meer svvieren.Oft, Nu singt, nu springt, &c.
******* DEVIATION POINT: svvieren.<*HERE*>Oft, Nu si
In the first example, a space is removed because of #88, but the enrichment doesn't reflect that because it was done with the older version, so a space="no"
attribute is missing on the token "Amand" and we have a consistency issue.
In the second example, the </t-style>
rather than before according to the new rules after #88). In this case we are again missing a space="no"
attribute on a token, causing the inconsistency.
A third example:
<t>NIemand, die zig maar eenigzints met de Wereld, ik wil zeggen, met Wereldsche noodzakelyke Bezigheeden, Bedryven en Hanteeringen, ophoud, waaronder 100, ja 1000derley nuttige en nootwendige dingen begrepen zyn, hier ondoenlyk en onnodig alle op te noemen, is onbekent, hoe nuttig en dienstig de zo genaamde <t-style class="i">Couranten </t-style>of<t-style class="i"> Nieuws-Papieren </t-style>zyn, namelyk, om dezelve te lezen: Dat dus ook niemand ontkennen zal, die deze zake maar eenigzints met een Oog van dieper inzigt en met een groter overleg aanmerkt als het Gemeen; waar over we nu in 't begin van onze Redenering niet zullen uitweiden, alleen voor eerst maar zeggende, dat 't om de Nuttigheid der Couranten is, waarom het in alle Landschappen van Europa, en zelfs verder, geoorlooft is, en van de Hoge Regenten gepriviligeert word, om Couranten uit te geven, die vervolgens elk kopen en lezen kan, om te hooren wat 'er in de Weereld omgaat, 't welk we in 't vervolg staan nader op te helderen.</t>
Here we would obtain "CourantenofNieuws-Papierenzyn" due to the odd formatting that's no longer compatible with #88.
I'm proposing the following solution:
If there is a text consistency error, check whether the error would also occur in the old situation prior to #88 where leading/trailing whitespace was not stripped. If things are consistent according to the old rules, then the consistency error becomes a warning rather than a hard error. This way we preserve backward compatibility while still explicitly communicating that the newer situation is preferable.
Ideally, at some point we implement an algorithm to automatically fix this issue, in foliaupgrade
, but this involves quite some complexity (and the text consistency validation is already complex enough as it stands).
This is what we get now with the solution in place, it's verbose but it gets the message across I think:
$ foliavalidator ~W/folia/examples/tests/issue92_2.2.0.folia.xml
TEXT VALIDATION ERROR: Text for <Paragraph at 139731618099936 id=weve002leve01_01.text.div.1.div.1.p.14 set=https://raw.githubusercontent.com/proycon/folia/master/setdefinitions/tei2folia/paragraphs.foliaset.ttl class=p>, is inconsistent: EXPECTED (after normalization) *****>
Van dit belangrijk dichtwerk is slechts één afschrift bekend, mogelijk het oorspronkelyke, daer het geschrift tot de XIVe eeuw schijnt te behooren. Het is een boekdeel in papier, kl. quarto-formaet, en berust in de stadsbibliotheek te Gent. Het Leven van S. Amand , bevattende 12,467 verzen, staet vooraen in het boek, en neemt de 236 eerste bladzyden in. Verder behelst dezelfde band nog twee opstellen door dezelfde hand geschreven: het Tondalus-Visioen in proza, en een Glossenlied op het Ave-Maria; beide deze stukken gaf ik reeds in het II.e Deel der Oud Vlaemsche gedichten der XIIe en XIIIe eeuwen in het licht.
****> BUT FOUND (after normalization) ****>
Van dit belangrijk dichtwerk is slechts één afschrift bekend, mogelijk het oorspronkelyke, daer het geschrift tot de XIVe eeuw schijnt te behooren. Het is een boekdeel in papier, kl. quarto-formaet, en berust in de stadsbibliotheek te Gent. Het Leven van S. Amand, bevattende 12,467 verzen, staet vooraen in het boek, en neemt de 236 eerste bladzyden in. Verder behelst dezelfde band nog twee opstellen door dezelfde hand geschreven: het Tondalus-Visioen in proza, en een Glossenlied op het Ave-Maria; beide deze stukken gaf ik reeds in het II.e Deel der Oud Vlaemsche gedichten der XIIe en XIIIe eeuwen in het licht.
******* DEVIATION POINT: n S. Amand<*HERE*>, bevatten
However, according to the older rules (<v2.4.1) the text is consistent. So we are treating this as a warning rather than an error. We do recommend fixing this if this is a document you intend to publish.
WARNING: Document (/home/proycon/work/folia/examples/tests/issue92_2.2.0.folia.xml) uses an older FoLiA version (2.2.0) but is validated according to the newer specification (2.4.2). You might want to increase the version attribute if this is a document you created and intend to publish.
WARNING: there were 1 text validation errors but these are currently not counted toward the full validation result (use -t for strict text validation)
Validated successfully: /home/proycon/work/folia/examples/tests/issue92_2.2.0.folia.xml
This has now been implemented in both foliapy (released) and libfolia (not yet released)
We introduced a problem with #88 that breaks backward compatibility. In Nederlab we have a file with (note all the spacing and newlines):
This passed validation for FoLiA <v2.4.1, but now with FoLiA >=v2.4.1 it fails with a text consistency problem:
Foliapy and libfolia are consistent in reporting the error. I'm still investigating why it goes wrong exactly. Obviously, we fixed #88 for a good reason, but we also don't want to invalidate older FoLiA files that were valid before. Ideally, we find a solution that maintains the solution in #88 and also validates against these older files. Otherwise we will need a patchy solution so the newer validator doesn't invalidate the older FoLiA.
To be continued...