Hi all, I'm sorry but I too will need to miss the stylesheets meeting today, a thing came up at work that will directly overlap. I will see you Saturday for the F2F, though. Meaghan On Wed, Jan 27, 2021 at 12:40 AM Elisa Beshero-Bondar wrote:

Alas, I am sorry to miss this Stylesheets meeting on Thursday as I have an unavoidable conflict. But I will see you all soon after for the F2F and Janelle, we can still meet as planned later on if you like!

Elisa

Elisa Beshero-Bondar, PhD Program Chair of Digital Media, Arts, and Technology | Professor of Digital Humanities | Director of the Digital Humanities Lab at Penn State Erie, The Behrend College

Typeset by hand on my iPhone

On Jan 26, 2021, at 4:35 PM, Bauman, Syd wrote:

 On Tue 28 Jan 21 at 19:00Z we are planning to discuss (and maybe try to fix) Stylesheets #237 https://github.com/TEIC/Stylesheets/issues/237.[0] This is a complex issue, and I encourage each of you read this, think about it, and maybe even work on it a bit before the meeting.

Here are some bird’s-eye[1] thoughts on the matter.

When an element or attribute is added to a TEI customization, there are a variety of naming possibilities:

- the element (or attribute) may have a local name that is - the same as the local name of an existing TEI element (or attribute) - NOT the same as any existing TEI element (or attribute) - the namespace for the new construct may be - null (i.e., in no namespace), - the TEI namespace, or - some other (non-null, non-TEI) namespace.

The original post was a complaint that when a user tried to add an attribute in a non-TEI namespace whose local name was the same as an existing TEI attribute, he got erroneous output RELAX NG — duplicate definitions of the attribute or undefined patterns.[2] I suspect (but have not tested) that the difference of which error is based on the value of @mode and on whether the attribute (both original and re-definition) was defined in a class or on an element.

This set of possibilities multiplies quickly. This is a chart of what the user wants to add. It does not include *how* it is added, i.e. the value of @mode and whether classes are involved or not (and how). In this chart, those listed with *italics* in column 1 seem to me to be less important to support, and those that are *bold* seem to me to be very important to support.

adding an … name- space local name comment *element* null existing Non-conformant; very discouraged *element* null new Non-conformant; very discouraged element TEI existing should be a "replace" *element* TEI new Non-conformant; discouraged *element* other existing

*element* other new

attribute null existing should be a "replace" attribute null new maybe should be discouraged? *attribute* TEI existing Non-conformant?; discouraged *attribute* TEI new Non-conformant?; discouraged *attribute* other existing

*attribute* other new

For each supported combination of generating a new element or attribute (i.e., those in the above chart we decide to support, whether created via a class or directly in an <elementSpec>) we need to worry not only that the RNG schema generated is valid and correctly represents the new structure (which means, among other things, the new structure has a different pattern name[3] than any existing TEI structure), but also about how the new structure is referred to from within the PureODD itself. (In ODD you could refer to the new structure by using its RELAX NG pattern name.[3])

That is, if I define a new syd:witness element in my customization ODD, and do not want it to be a member of any model classes, but rather only want it as a direct child of <div2>, how do I do that?

- <elementRef key="witness"/> (probably gets the <witness> from the textcrit module) - <elementRef key="prefix.witness"/> (where “prefix.” is the value of @prefix of the nearest ancestor of the <elementSpec> that defines syd:witness that has an @prefix, taking <specGrpRef> into account) - <elementRef key="syd:witness"/> (in which case, how do the Stylesheets know what namespace “syd:” resolves to?)

I am not sure this can been done in the current PureODD. I think we may need to add a mechanism for this purpose. Either some way to define the prefix, or adding an @module to <elementRef> or something. Martin, Nick, and I were initially leaning towards adding an @ns to <elementRef>.

*Notes* [0] Via a Zoom link that Martina will send out ~1 hour before the meeting. [1] By which I mean “aerial” or “overview”, not this https://www.dropbox.com/sh/nz7vhjtq8physey/AAAFtWpo2qUCxswupOwXqz5Ga?dl=0, which are pictures from the Birds of Prey show that Martina, James, Martin, and I attended (along with Kathryn Tomasek, Georg Scholger, Anne Bauman, and Helmut Klug — am I missing anyone?) after the 2019 TEI Conference & Members’ Meeting in Graz. Again, a huge thank you to Georg and Martina for hosting this event. [2] And David Maus, who I think is a wonderful chap, suggested in PR #2069 https://github.com/TEIC/TEI/pull/2069 that the answer should be to *require* a namespace prefix in the @ident of an <attDef> that has an @ns attribute. While I am not convinced that would currently work even for the case he has in mind, let alone for other combinations above, it is not at all crazy. [3] The “pattern name” is the name used in the RELAX NG output to refer to the new construct. E.g., if you look for the definition of the element <head> in tei_customization.rng https://jenkins.tei-c.org/job/TEIP5-dev/lastSuccessfulBuild/artifact/P5/rele... you will find that the <element name="head"> is the one and only direct child of a <define name="cust_head">. The “cust_head” is the pattern name, and it is how the <head> element is referred to in other parts of the schema. In many cases (e.g., in tei_bare, tei_corpus, and tei_drama) there is no prefix, and the pattern name of an element is the same as the name of the element, and the pattern name of an attribute can easily be derived from the attribute name and the class in which it is defined (e.g. “att.ascribed.attribute.who”); in several cases (tei_allPlus, tei_customization, tei_its, tei_math, and tei_svg) there is a prefix, typically defined using the @prefix of <schemaSpec>. ------------------------------

We are scheduled to hold a Stylesheets meeting on Thu 28 Jan 21 from 19:00Z to 20:30Z. That’s

- 11:00–12:30 PST - 14:00–15:30 EST - 19:00–20:30 GMT - 20:00–21:30 CET

We have not decided yet on a platform (although it seems to be Zoom vs Google Meet), or who will be hosting.

Per last week’s Council meeting, our main topic will be Stylesheets #237 https://github.com/TEIC/Stylesheets/issues/237. I hope to post a bit of a summary and some thoughts on this issue by the beginning of next week, but not guarantees. _______________________________________________ Tei-council mailing list Tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

_______________________________________________ Tei-council mailing list Tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

-- Dr. Meaghan Brown