Hi Martin, that is a very interesting question which I’m not able to answer but it evokes even more questions for me. I consider "ODD chaining" actually as „ODD graphing“ – you don’t have a chain of succession leading back to one base ODD but in fact your customization may cherry pick from various sources turning it into a graph of dependencies. So I guess the task is to find the leaves of the tree; but those leaves are not necessarily whole documents but could be individual specifications within larger schemaSpecs. So consider an element spec like <elementSpec ident="my-milestone-element“ ns="me"> <content> <empty/> </content> </elementSpec> which I consider complete. Even if this was defined in some customization based on some other source I believe there’s no need to look further for an ODD customization referring to this particular element. (You might eventually run into infinite loops if you're trying to look further?) Does that make sense? Cheers Peter
Am 12.02.2025 um 19:27 schrieb Martin Holmes <mholmes@uvic.ca>:
Thanks Raff -- we were in fact looking at the MEI base ODD this morning, and it helped us to reach this conclusion.
I believe MEI is the most complex non-TEI ODD-defined language; EpiDoc is a direct customization of p5subset, assuming <https://github.com/EpiDoc/Source/blob/main/schema/tei-epidoc.xml> is their current ODD file. If anyone knows of any other non-TEI schema definitions in ODD, we'd like to look at those too.
Cheers, Martin
On 2025-02-12 10:17, Raffaele Viglianti wrote:
Hi Martin, I think this makes sense and currently the MEI source at https:// raw.githubusercontent.com/music-encoding/schema/refs/heads/main/5.0/mei- source_canonicalized_v5.0.xml <https:// can01.safelinks.protection.outlook.com/? url=https%3A%2F%2Fraw.githubusercontent.com%2Fmusic- encoding%2Fschema%2Frefs%2Fheads%2Fmain%2F5.0%2Fmei- source_canonicalized_v5.0.xml&data=05%7C02%7Cmholmes%40uvic.ca%7C1a135d2acb3142728eed08dd4b917122%7C9c61d3779894427cb13b1d6a51662b4e%7C0%7C0%7C638749810513554853%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=xvhguwdZLed6WFvG1sCSCkhZj%2BJA1dGdBocu%2BYFImaI%3D&reserved=0> would fit of the requirements (<schemaSpec> with no <*Ref> children). In the past, I have been using the --localSource parameter to override p5subset with the MEI source, essentially setting the base odd for further chaining. Raff On Wed, Feb 12, 2025 at 12:47 PM Martin Holmes <mholmes@uvic.ca <mailto:mholmes@uvic.ca>> wrote: Hi all, The ATOP group has been grappling with the issue of ODD chaining, and in particular, how to determine, starting from a customization ODD to process and following its chain of precursors, how to know when you reach a base ODD and don't have to go any further. This is easy if the ultimate base ODD is p5subset, and that is indeed the default. However, it's perfectly possible that you don't want anything at all from P5, you just want to customize a base ODD that you've already created. One obvious sign of a base ODD is that there is no <schemaSpec> element -- which is the case for p5subset -- but we know that many base ODDs in the wild DO have a `<schemaSpec>` element, and it also seems intuitive that if you're creating a schema specification, you should use a `<schemaSpec>` element. So we've arrived at a definition of a base ODD, which we believe is testable; it goes like this (adapted from our meeting notes): EITHER the ODD has no `<schemaSpec>` element, OR it has a <schemaSpec> with no `@source` (meaning that the source would default to p5subset), BUT there are no `<*Ref>` children of that `<schemaSpec>` invoking content from p5subset so there is no need to retrieve it. This is based on the assumption that if you use any `<*Ref>` element at the base level (i.e. as a direct child of `<schemaSpec>`), that constitutes a call to retrieve something from p5subset; but any such `<*Ref>` at a lower level must be referring to what is already in the schema (either because it's locally defined, or because it was brought in by a top-level `<moduleRef>`, `<elementRef>`, etc.). So my question is: does all this make sense to you all? If so, and we proceed on this basis, then P5 could probably use some more explanation of what a base ODD is, and how it fits into the chaining process. I should also say that current approaches to ODD chaining with the current Stylesheets involve pre-compiling any ODD which is earlier in the chain, so that it constitutes a .processedodd file (see <https://teic.github.io/PDF/howtoChain.pdf <https:// can01.safelinks.protection.outlook.com/? url=https%3A%2F%2Fteic.github.io%2FPDF%2FhowtoChain.pdf&data=05%7C02%7Cmholmes%40uvic.ca%7C1a135d2acb3142728eed08dd4b917122%7C9c61d3779894427cb13b1d6a51662b4e%7C0%7C0%7C638749810513568694%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Ki3SQXjR7lCGt4eKgNupppRzUWWnwUNKkSn3IN714eY%3D&reserved=0>> section 4), but we would like ATOP to be able to do all that automatically, so that all you do is specify the source for your customization, and the processor can construct the entire chain and compile everything in sequence. Cheers, Martin -- ------------------------------------------ Martin Holmes UVic Humanities Computing and Media Centre I acknowledge and respect the lək̓ʷəŋən peoples on whose traditional territory the university stands and the Songhees, Esquimalt and WSÁNEĆ peoples whose historical relationships with the land continue to this day. _______________________________________________ Tei-council mailing list -- tei-council@lists.tei-c.org <mailto:tei- council@lists.tei-c.org> To unsubscribe send an email to tei-council-leave@lists.tei-c.org <mailto:tei-council-leave@lists.tei-c.org>
-- ------------------------------------------ Martin Holmes UVic Humanities Computing and Media Centre
I acknowledge and respect the lək̓ʷəŋən peoples on whose traditional territory the university stands and the Songhees, Esquimalt and WSÁNEĆ peoples whose historical relationships with the land continue to this day.
_______________________________________________ Tei-council mailing list -- tei-council@lists.tei-c.org To unsubscribe send an email to tei-council-leave@lists.tei-c.org