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 <s.bauman@northeastern.edu> wrote:



On Tue 28 Jan 21 at 19:00Z we are planning to discuss (and maybe try to fix) Stylesheets #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, 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 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 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. 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