You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 11, 2023. It is now read-only.
The description for this template includes the comment "This allows you to validate TEI documents before XInclude processing. In general, this is not the right way to work, since you would normally validate after any inclusions have been resolved. "
If it's not the right way to work it probably shouldn't be being offered as a template.
see also appended discussion on TEI-L
On 10/12/15 10:56, Piotr Banski wrote:
Maybe that ODD should best move from Roma's menu to the wiki, because it has the potential to confuse or at least to suggest that injecting Xincludes into the TEI schema is the natural, or worse, the recommended way to go.
Best,
P.
On December 10, 2015 11:50:21 AM CET, Lou Burnard wrote:
Sorry, this makes no sense to me. If the document you want to validate
contains xInclude statements in the place of mandatory elements, it can
ONLY be validated against a TEDI schema by expanding the xInclude
statements. Otherwise you would have to redefine the content model of
the header entirely to permit unexpanded xInclude elements everywhere,
which would make it no longer TEI conformant.
On 10/12/15 10:34, Andreas Wagner wrote:
Dear Piotr, dear list,
* Piotr Bański dixit [2015-12-10 09:53]:
The fundamental question is whether anything hinges on your _not_
resolving the XIncludes prior to validation.
Yes, indeed. I explicitly
wanted to do it *without* oXygen doing the
XInclude resolution, but funnily I can't remember why. For now I am
doing it the way you suggested. Thank you for the suggestion.
Just for the record, if it turns out I really want to do it without
XInclude resolution after all, and want to validate the *including*
TEI document (which contains XInclude statements instead of mandatory
elements such as publicationStmt), I would have to take the ODD route,
wouldn't I? And how would I go about this?
The text was updated successfully, but these errors were encountered:
The ODD appears to be more like an example for tinkerers (vide Martin Holmes' next message in the thread cited). Obviously, one could argue that the others are mostly also merely starters that can or should be further customized, so I can understand the difficulty in drawing the line.
How about pushing the "TEI-defined customizations" to the very top of the list, to indicate that whatever comes below is already in the tinkering range? Naturally, this wouldn't solve the problem at hand, but I am now beginning to wonder if the problem is solvable -- I really don't know where to make the cut between what should stay on the front Roma page, and what should be delegated to http://www.tei-c.org/Guidelines/Customization/#community
(Take e.g. the ODD for linguistic corpora -- I've put together many corpora in the TEI, and I think I have never used that ODD except for the very first time, and even then after a while I customized the ODD beyond recognition anyway. My newest corpus is nowhere near it.)
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The description for this template includes the comment "This allows you to validate TEI documents before XInclude processing. In general, this is not the right way to work, since you would normally validate after any inclusions have been resolved. "
If it's not the right way to work it probably shouldn't be being offered as a template.
see also appended discussion on TEI-L
On 10/12/15 10:56, Piotr Banski wrote:
The text was updated successfully, but these errors were encountered: