TEI Technical Council virtual “F2F”, 2020-05-01 / 05-03

TEI Technical Council virtual F2F meeting: 1–3 May 2020 plus add-on sessions on May 5, 12, and 19.

Friday, May 1 09:00–13:00 EDT  / 14:00–18:00 BST / 15:00–19:00 CEST Council meeting
Saturday, May 2 9:00–12:00 BST / 10:00–13:00 CEST European break-outs
09:00–13:00 EDT / 14:00–18:00 BST / 15:00–19:00 CEST Council meeting
15:00–18:00 EDT American breakouts
Sunday, May 3 09:00–13:00 EDT / 14:00–18:00 BST / 15:00–19:00 CEST Council meeting

Present:

Apologies/Not Present:

Friday, May 1 (full Council)

started ~13:13Z, finished ~16:58Z Next release

Guidelines for Recusal from the TEI Technical Council

Restructuring Chapter 11

Framing discussion: standOff, annotations, Web Annotation Model, and extraTextual

Roma

Report on OJS migration

Stylesheets issues triage

Saturday, May 2

European break-outs

started ~10:05, ended ~12:58

Full Council meeting

started ~13:07Z, ended ~17:12Z

American break-outs

started ~19:06Z, ended ~22:07Z

Sunday, May 3

Full Council meeting started ~13:06Z, ended ~17:06Z

Discuss issues from American break-out group

<standOff>, annotations, and the Web Annotation Model

<annotation>
  <ptr type="target" target="https://example.com/target"/>
  <ptr type="body" target="https://example.com/target"/>
</annotation>

<annotation>
  <ptr type="target" target="https://example.com/target"/>
  <note type=”body">I am the body (but Schematron limits me to sanity)</note>
</annotation>

Discussion on TEI+RDFa issue

Collaborative TEI editor (presentation NC)

Documentation

Tue, 05 May

Council extended its VF2F meeting by another 1.5 hours. Started: ~13:04Z.

Tue, 12 May

Started @ 13:05 with: SB, EB, MB, HC, JL, MS, PS, RV

Repeating sub-group information for ticket charts:

Tue, 19 May

Started @ 13:05 with: SB, EB, MB, HC, NC, JL, MS, PS, MT, RV

Status: Needs discussion

No. Group Title Comment
European Group:
#1582 A phrase-level TEI elements should be allowed inside <sch:assert> and <sch:report> Group A thinks that this should be green and that model.phrase.xml should be allowed.
#1604 B `@source` on schemaSpec should be only a single pointer Has anyone tested Lou’s assertion that multiple values work? —SB Looks like an approach was agreed: continue to allow multiple values, document, and check that it works. Already assigned to SB.
#1606 A dataRef should not permit @restriction and @key Have a Schematron rule to enforce that @key or @ref and @restriction cannot be used together, e.g <sch:rule context="tei:dataRef[@key]”> <sch:report test="@restriction" role="nonfatal">The attribute @restriction cannot be used in conjunction with @key.</sch:report> </sch:rule>
#1632 B egXML needs a way to highlight rendtitional aspects in the example c.f. #1928 Looks like it should probably be a <standOff> annotation to me (NC). Low priority?
#1658 A <q> should be allowed in <span> This may be solved with issue #1918, subgroup not against the idea.
#1661 B Need <surplus> in <subst> Why is <surplus> inside <subst>?  Wouldn’t that mean that *all* <surplus> tags are inside a <subst> (logically?) (NC). We agree with Lou’s comment from 2017. Recommend to close.
#1675 A Check teidata.pointer attribute values starting with # to ensure they are proper xml:id's We agree with JC’s proposal. Raise warnings only. Make Green for Go. (MT: cf https://github.com/eXist-db/exist/issues/540 and related https://github.com/relaxng/jing-trang/issues/188)
#1698 B The namespace could be mentioned more prominently in the guidelines Add a new appendix. Not over-kill — it would be clearer. Make this ticket green. Should mention http://tei-c.org/ns/examples/ as well as http://tei-c.org/ns/1.0/.
#1710 A Review placement of classes, macros, and datatypes in modules Recommend deprecation period for changes which move classes from tei module to only specific module; rule of thumb would be to investigate candidates from classes only used in a single module but still evaluate one by one if they are potentially to be used more general e.g.* att.damage seems to be only applicable in the transcr module so should not be by default available in tei * att.datable.custom should probably stay in namesdates, even though it is used in tei indirectly via other classes because you don’t want it unless you are doing specialised stuff
#1721 B multi-lingual tei and xml This should probably be discussed by the i18n working group? NC: This seems to be an edge-case, but if TEI is XML, we should probably align more closely with the XML spec — though I’m not totally clear how we are deviating. Syd’s comment on 6 Dec. 2017 appears very sensible.  This could take up a lot of time for an edge-case. NC: Michael Sperberg-McQueen says in 28 Nov 2017 that: “The XML spec does not require that the value of @xml:lang be interpreted as applying to all attributes -- I take the intent to be that it applies to those with free natural-language content.” Case closed.
#1722 A Warnings in Jenkins based on TEI_to_odd4odds.xslt Set to status=Go. Prod SB.
#1724 B inconsistency in datatypes of key= and ident= Would be nice to align those datatypes. Our proposal would be to choose teidata.name since it’s the superclass (thus keeping backwards compatibility) and allows for future namespacing of modules etc.
#1729 A inconsistency in reason attribute definition for gap and unclear Status=Go. Prod SB to provide description for eccentric_ductus.
#1745 Standoff: annotation microstructure See discussion on Sunday
#1776 B add <w> to att.lexicographic Looks as if it should be green; ask MT and EB about the current status. (Council greenlights this with requested modification to @bansp's pull request)
#1781 A Mysterious schematron constraint in simplePrint Easy: Just remove https://github.com/TEIC/TEI/blob/dev/P5/Exemplars/tei_simplePrint.odd#L4540-L4547 constraintSpec entirely. We don’t think we want it.
#1787 B Feature Request: `<projectDesc>` content model needs to be richer Responsibility statements about the project can be captured in a structured way in the title statement.  <projectDesc> is defined by the Guidelines as a prose field. The proposed tags in the proposal fit well into the <titleStmt>. Implementing this would mean that there is a confusion about where things should go. The naming of the prose field has caused confusion — the whole formal description of the project is the title statement and this additional prose field. Recommend close. (NC)
#1800 A more on dictionary: The element <usg> inside <def> <usg> should be allowed inside <def>, no reason not to do it. Recommend Green Status
#1851 B msContents/msItem should be replaced in tei:object with something non-MS specific P6-dev? Ask JC. JC: Should be done as soon as possible. Having hybrid is problematic. Planning to get around to it over summer for a first draft proposal at least.
#1856 A `<ab>` should be able to nest Close ticket: discussion has been going for a long while but all the examples presented still remain unconvincing; recommend closing the ticket with a note to that effect and softening remark that obviously issue could be reopened if new examples, less controversial, are provided. MS intends to revisit her material to search for use cases that would justify the need for nested <ab>. At that point she may reopen the ticket.
#1857 B `<egXML>` should be able to nest The final comment on https://github.com/TEIC/TEI/issues/1798 was this was actually already valid. JC says that we should not encourage this further (except for examples of egXML). Unclear what the consensus is or was, or what the technical challenge of validation is. Council notes that <egXML> should contain anything, so why wouldn't this be allowed? SB notes that it's definitely not allowed...but we should investigate why: probably a Stylesheets processing issue.
#1858 A <q> should be allowed in <byline> While this may be solved with issue #1918, we might as well go ahead and do it now. Status=Green/Go.
#1860 B Encoding RDF relationships in TEI (TEI+RDFa and alternatives) RDFa is a set of attributes that could well be incorporated as an attribute class (with prefixed attributes names, e.g. `rdfa:about`) in TEI. Or add an customization TEI+RDFa in exemplars. Needs discussion with the whole Council. What about not including it, but rather using it as an example for how TEI can be mixed with other standards? (see discussion on Sunday)
#1861 A Feature Request: <listFigure> element Ask Joey Takeda and EB to come up with a proposal with pros/cons. Options include just using <list>, adding <figure> to <listBibl>, or new <listFigure> element. Council notes that we should go ahead and work on this, probably use @copyOf on <figure>,  added MS to the ticket.
American Group:
#1769 C teidata.pointer equivalent to move/@where Group thinks HC's suggestion would work, and he should emend the pull request accordingly.
#1805 D Suggestion for new uniHan element Ongoing. MS identified phases on 4/15/20. Action on RV to check in with Duncan Paterson. re: movement on phase 3 onward.
#1869 C ODD spec elements should have their own source attribute Ask SB why decision wasn’t implemented? Subgroup suggests remove needs discussion label. Discussion 5-12: Some concern that introducing this new attribute will break people's ODDs. Connection to #1604
#1870 D seriesStmt needs better examples, use of biblScope Subgroup thinks EB can move forward with updating <biblScope> example and prose for <seriesStmt>. Further discussion of relevant elements for <biblScope> and its distinction from <citedRange> needed. Action on RV (or better MS) to reach out to Daniel Schwartz re: multiple <seriesStmt> for his project. [Daniel Schwartz has since replied on the ticket.] 05-12 discussion: Council thinks we may want to permit multiple <seriesStmt>s in the TEI header (open a new ticket for this, and indicate Council is in favor, but invite discussion from the community.) Action on EB to come up with an example that uses more than the standard limited things we've been using in examples of <biblScope>.
#1877 C FR for new `<elision>` element Council subgroup ultimately likes the proposed element and its content model, so long as we have a clear explanation that this is material purposefully omitted in the source. But we're still uncertain of the appropriate name: <elision>, <ellipsis>, or <omitted>? Council favors <ellipsis>
#1879 D New element listNote as a wrapper for note elements Subgroup suggests broader all-Council discussion. 5-12 Council discussion: Make sure we're clear on the difference between <noteGrp> and <listNote>. <noteGrp> would be clustering notes about the same thing. Also it needs to be clear how this relates to / collides with <listAnnotation>. (Is <listAnnotation> confined to WADM?) In general it's confusing to understand the semantics of *Grp Usually we use *Grp to associate the same things (except for <personGrp>).
#1880 C investigate adding note to macro.limitedContent Subgroup thinks this probably isn't going to hurt anything, though macro.limitedContent is already probably overused. Council discussion 5-12: We can't/shouldn't really do this because <note> is in model.global. Close wontfix.
#1891 D Extend the content model of cit to include model.segLike Subgroup thinks allowing <pc> is good idea, but not on board with model.segLike. May also want to consider <cit> definition & examples vs. common usage. Full Council agrees to green light for adding <pc> only.
#1908 C Bad examples for definition of org/@role Titular issue is resolved, but subgroup also approves of JC’s suggestion of adding teidata.enumerated. We recommend greenlighting for this alteration. Council greenlights JC's suggestion to change the datatype or @role to teidata.enumerated.
#1910 D Add location information to the new `<conversion>` element Subgroup suggests closing ticket, unless OP returns with additional issues following <listPlace> solution. After discussion, most of Council agrees with implementing @where on <conversion>, and we want an attribute class for @where to be used as it is on <event>. But putting multiple values on @where seems problematic for keeping this definition consistent with its use on <event>. We are considering an attribute class, att.locatable and will open a new ticket about this. MT wants to work up a couple of examples to see if @where really makes sense here. SB to post examples changing to single value for @where.
#1911 C material element should be in att.typed Subgroup recommends defining @function on <material>. Council discussion: We favor adding @function as well as adding <material> to att.typed. We need to further investigate how @function aligns with its use on <metamark> and att.segLike.
#1914 D Add modelGraphic.Like to the content model of <cit> (allow <media> in <cit>) Subgroup thinks model.graphicLike should be added to content of <cit> to allow for media. Council after long discussion (considering whether <figure> would be enough, and deciding it would not be) finally agrees to greenlight this and add model.graphicLike to <cit>.
#1955 C FR: TEI Features for CMC Subgroup likes this, and wonders if this should be a new chapter to the Guidelines, and should Council task a working group to prepare it? VF2F2020: Council decides those assigned to this ticket will meet to review the proposal carefully, see how it best fits into the Guidelines—perhaps as a new chapter—and return to the working group with a proposal for how to proceed. Action on SB, PS, JL.
#1967 D <linkGrp> needs <head> and <desc> Subgroup is generally okay with adding <desc> but suggests some further discussion, esp. re: need for <head>.
The following issues were discussed by the American break-out-groups, but there was no time to review them with full Council. This will be done in the monthly meetings.
#1916 C Corpus Exemplar should more explicitly state what it's for Subgroup agrees with Martin Holmes, we should recommend oXygen proceed with changing the template file names on disk. Open a ticket on oXygen or contact Radu Coravu?
#1917 D Guidelines "XML syntax" button is broken Ticket closed. Suggest Martin Holmes to open a new ticket for getting rid of JQuery and allowing info for attributes in content models.
#1918 C Investigate changing the class membership of <q> Done. Green.
#1919 D category, taxonomy, and joinGrp should not have model.glossLike in their content models Subgroup thinks this is low priority, but should investigate removing <altIdent> from <category>, <taxonomy>, and <joinGrp> (but perhaps not via model changes).
#1921 C Remove <schemaSpec> from model.divPart and add to small set of elements Subgroup totally agrees with JC. We really need to de-class-ify this.
#1925 D <equiv> should get the @predicate attribute Subgroup suggests Status:Go, with @predicate put in a class.
#1928 C Substring highlighting for egXML Great idea (JC). We should close one of these tickets as superfluous. See also #1632.
#1929 D What is a paragraph, really? Subgroup greenlights EB to revisit definition/description of <p>, but any concrete change to the Guidelines would warrant further discussion.
#1931 C Examples in P5 are unnumbered Subgroup recommends that we rethink how we deal with examples generally (connected with highlighting, too, and i18n group's needs to prioritize examples in particular languages). For now, we should consider it low priority. JC notes he is writing an article for jTEI about some of the issues with examples.
#1933 D exemplum and language Subgroup suggests this ticket for consideration by i18n group.
#1934 C Categories of uncertainty Greenlight to add to att.typed
#1937 D slightly expand <content> descendants' namespace to a: Subgroup suggests closing ticket unless OP returns with objections.
#1939 C Content models for <front> and <back> identical? Subgroup agrees that <front> and <back> should be identical, and that model.divBottom does indeed belong in <front> as well as <back>. We should greenlight to try to implement.
#1942 D Unused test files should be removed Subgroup changed to Status:Go.
#1943 C Allow <bibl> in <label> HC will write to Scott to prod him for an example.
#1945 D lg element content model prevents accurate encoding Subgroup thinks this ticket can be deferred in favor of #1877, which may solve the issue.
#1946 C No column- nor row-spanning examples? Subgroup likes the example and thinks this needs to be greenlighted.
#1947 D Two more values for teidata.certainty Subgroup suggests closing ticket unless OP returns with objections.
#1951 C Wrong article? Subgroup greenlights as this is super simple.
#1953 D improve example Subgroup suggests change Status: Go. Note: very American example
#1956 D Broken/misdirecting links Subgroup suggests change Status: Go to fix SourceForge reference, noting that  OP’s issues have already been resolved (links fixed).
#1957 C FR: Declarative Citation Structure Subgroup likes this and observes we need to review HC's PR. Action on EB, MS, and PS to review.
#1961 D inconsistent indication of elided content in examples Subgroup suggests greenlighting this ticket and assigning it to a new Councilmember (JL).
#1962 C Make Licensing explicit in repo Subgroup totally agrees with this; it should be green. We need to add BSD-2 and CC-BY to the TEI repo. Should it apply to other repos in TEI-C as well? There is one already on Stylesheets repo.
#1963 D WD should refer folks to the Script Encoding Initiative Subgroup suggests change Status:Go, no further discussion needed.
#1966 C Inconsistency in character representation Subgroup agrees with SB that this needs careful investigation to determine whether some of these inconsistencies are actually appropriate/deliberate.
#1973 C add class att.normalized for att.lexicographic and att.linguistic to include Subgroup notes we already discussed this in connection with #1776.
#1984 C Guidelines TOC page should use HTML5 summary/details elements instead of JS Subgroup thinks this is a great idea. Stylesheets might complicate its implementation, but we should greenlight to try it.
#1986 C add altIdentifier to att.datable Subgroup agrees that <altIdentifier> should be added to att.datable, but NOT <msIdentifier> because that should always be the current one. No-one asked for it (HC wants this to become a new doctrine).
#1987 D Remove unnecessary comments from ODD customization exemplars Set as Green?
#1988 C Schematron constraint for ab is too crude Subgroup agrees with the recommendation to amend the Schematron to recognize the special "floating-text-like" contexts for things like <ab> and <p>. Recommend greenlighting.

Status: Needs discussion and Go

This means that we have already discussed this issue and that the assignee will come back to Council with a proposal on how to implement the issue. Please check (initials of assignees are in the comment) if there has been some progress since we last discussed this. If not, we don’t have to discuss this during the F2F.

No. Group Title Comment
#1586 Domain of concept of cleanliness HC
#1715 Clarify description of att.combinable's "mode" RV
#1744 Add co-occurrence constraints to ODD RV
#1837 improve explanation of @defaultExceptions on schemaSpec SB, PS
#1849 Add more discussion of editorial practice to TC chapter HC
#1852 Define semantics of witDetail without @target HC
#1871 restore explanation of TEI namespace PS
#1873 Create Website Documentation Specifically Aimed at Developers PS
#1885 Update teidata.temporal.iso (and teidata.duration.iso?) HC, SB, MH
#1902 Add model.biblLike to model.entryPart.top MB (MS: I think this can be marked as green?)

Pull requests

No. Group Title Comment
#1920 WIP: draft implementation of noteGrp MT: I would like to ask review, if the approach to just copy <attList> from <note> since <noteGrp> should have the same is the correct solution, or should these be factored out by means of an attribute class or other (@anchored and @targetEnd)
#1972 add att.normalized to hold @orig and @norm, and documentation to DI and AI MT briefly reviewed already and asked changes from att.normalized to att.lexicographic.normalized as discussed during the VF2F