There is oe maybe was also the i18n tagset developed by sebastian and felix sasaki of w3c 

Sent from Outlook for Android

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