Skip to content
This repository has been archived by the owner on Nov 11, 2023. It is now read-only.

TEI with xinclude template is confusing and should be removed #9

Open
lb42 opened this issue Dec 10, 2015 · 1 comment
Open

TEI with xinclude template is confusing and should be removed #9

lb42 opened this issue Dec 10, 2015 · 1 comment

Comments

@lb42
Copy link
Member

lb42 commented Dec 10, 2015

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?
@bansp
Copy link
Member

bansp commented Dec 12, 2015

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 free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants