search

kshawkin / Best-Practices-for-TEI-in-Libraries

Best Practices for TEI in Libraries: A guide for mass digitization, automated workflows, and promotion of interoperability with XML using the TEI
http://purl.oclc.org/NET/teiinlibraries
32 stars 8 forks source link

rework ODDs into a single file to use new capability for generating multiple schema #80

Open kshawkin opened 6 years ago

kshawkin commented 6 years ago

The TEI Council is working on a new capability in the ODD language to allow a single ODD file to be used to generate different schema, with you specifying which one you want at the time of processing. Once this is working, we should rework our ODDs into a single file, which will be much easier to maintain.

lb42 commented 6 years ago

I'm not aware that any new capability is necessary for this. It doesn't work in Roma but there's quite a lot besides this that Roma doesn't do. When you do get round to thinking about this again, may I suggest that an odd chaining approach might be simple r.

sydb commented 6 years ago

Right, @lb42. @kshawkin had the tense wrong: it is the use of the --selectedSchema switch we are thinking of. Back when I invented our current convoluted system --selectedSchema did not exist or did not work at all; but now it works reasonably well, but has at least 1 bug that would hold us back. (I forgot the details, but in at least some circumstances a <specGrp> gets included in the output schema even though it is not referenced by anything inside the <schemaSpec> being processed.)

ODD chaining is, of course, a very reasonable approach to investigate. But in the meantime, as soon as the bugs for schema selection are fixed, I think we should switch to a single ODD file.

lb42 commented 6 years ago

Have you raised an issue for this bug or bugs? I saw MSM did, but then retracted it.

sydb commented 6 years ago

Oh, right! I had completely forgotten about the retraction. Maybe it won’t be a problem after all …

kshawkin commented 6 years ago

Syd realizes that while we could now do this, the current ODD processor would generate documentation as separate files for each level as well, which isn't what we want for the BPTL. So we'll leave the ODDs as they are for now.