What is a base ODD?
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> 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.
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/... 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> 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> 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 To unsubscribe send an email to tei-council-leave@lists.tei-c.org
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.
There is oe maybe was also the i18n tagset developed by sebastian and felix sasaki of w3c Sent from Outlook for Android<https://aka.ms/AAb9ysg> ________________________________ From: Martin Holmes <mholmes@uvic.ca> Sent: Wednesday, February 12, 2025 10:27:38 PM To: Raffaele Viglianti <raffaeleviglianti@gmail.com> Cc: TEI Council <tei-council@lists.tei-c.org> Subject: [Tei-council] Re: What is a base ODD? 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
Hi Lou, Do you know where the ODD files for those would be? There's a tei_its ODD file in the Exemplars, but it's a straight customization of P5. Cheers, Martin On 2025-02-12 10:42, Lou Burnard wrote:
You don't often get email from lou.burnard@retired.ox.ac.uk. Learn why this is important <https://aka.ms/LearnAboutSenderIdentification>
There is oe maybe was also the i18n tagset developed by sebastian and felix sasaki of w3c
Sent from Outlook for Android <https://aka.ms/AAb9ysg> ------------------------------------------------------------------------ *From:* Martin Holmes <mholmes@uvic.ca> *Sent:* Wednesday, February 12, 2025 10:27:38 PM *To:* Raffaele Viglianti <raffaeleviglianti@gmail.com> *Cc:* TEI Council <tei-council@lists.tei-c.org> *Subject:* [Tei-council] Re: What is a base ODD? 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 <https://can01.safelinks.protection.outlook.com/? url=https%3A%2F%2Fgithub.com%2FEpiDoc%2FSource%2Fblob%2Fmain%2Fschema%2Ftei-epidoc.xml&data=05%7C02%7Cmholmes%40uvic.ca%7C23b352e792154d44128d08dd4b95100a%7C9c61d3779894427cb13b1d6a51662b4e%7C0%7C0%7C638749826061742791%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=rNpPV%2F9fHqjyEv4lZ4LHraiT2Jm2YyAJv8lyD2YrtOs%3D&reserved=0>> 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 <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 <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
-- ------------------------------------------ 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.
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
Hi Peter, This is exactly the sort of question we're looking at. There's a distinction (or at least, we've always assumed there's a distinction) between an ODD which has external references (go get me this specific elementSpec from that URL, or get me this RNG pattern from that schema), and a customization being an explicit modification of a base ODD. ATOP has an Assembly stage where external references are resolved, but that's different from the Derivation stage, where the customization is applied as a sort of transformation of the base ODD. It's possible this is a sort of misconception, and we should treat e.g. TEI <moduleRef>s pointing to a p5subset base ODD as no different from external references to a random RELAXNG schema somewhere. But as far as I know, it's not normal to pull in external content and then modify it with a <*Spec> witn @mode="change". Helena or Syd may know better than me here of course, but my (so far unexamined) assumption has been that external references are simply imported intact and unchanged, while the components of a base ODD are subject to customization through <*Spec>s in the customization ODD. The idea that, in the absence of an explicitly-specified base ODD, the current p5subset is assumed is, I think, the result of the idea that ODD really is about customizing TEI. But since it's increasingly used to specify other, unrelated schemas, it might be an issue we should revisit. I have some ODDs which, when I process them with the current Stylesheets, are processed against p5subset, but use absolutely nothing from it, so that stage of the process is actually pointless. So the idea is that ATOP would be able to determine that my ODD is actually itself a base ODD, and not need to look around for a p5subset. Cheers, Martin Martin Holmes UVic Humanities Computing and Media Centre mholmes@uvic.ca ________________________________________ From: Peter Stadler <pstadler@mail.uni-paderborn.de> Sent: February 13, 2025 2:43 AM To: Martin Holmes Cc: Raffaele Viglianti; TEI Council Subject: Re: [Tei-council] What is a base ODD? 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://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FEpiDoc%2FSource%2Fblob%2Fmain%2Fschema%2Ftei-epidoc.xml&data=05%7C02%7Cmholmes%40uvic.ca%7Cfa3bcee730ed44b399cd08dd4c1b55cf%7C9c61d3779894427cb13b1d6a51662b4e%7C0%7C0%7C638750402616350554%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=F%2FEW1V9d7toocJ7lcXv%2FZHqJ77dh0arGdRBDnoybqNM%3D&reserved=0> 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://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fteic.github.io%2FPDF%2FhowtoChain.pdf&data=05%7C02%7Cmholmes%40uvic.ca%7Cfa3bcee730ed44b399cd08dd4c1b55cf%7C9c61d3779894427cb13b1d6a51662b4e%7C0%7C0%7C638750402619980922%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=9t83wVmsrR%2FJFDhVgZ8xWwzN2H8ydOHqZ6wmKMOgkpY%3D&reserved=0 <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
participants (4)
-
Lou Burnard -
Martin Holmes -
Peter Stadler -
Raffaele Viglianti