TEI Technical Council F2F Meeting in Newcastle, 11–13 September 2022
Meeting Times
Date | Time | Meeting of | Location |
---|---|---|---|
Sunday, Sept 11 | 09:30–12:30, break at ~10:45 14:00–17:30, break at ~15:45 | Full Council meeting * atop meeting | Percy Buildingin G.09 |
Dinner | TBC | ||
Monday, Sept 12 | 09:30–13:00, break at ~10:45 14:30–17:30, break at ~16:00 | Full Council meeting | Armstrong Building in G.09.KLLT |
17:30–18:30 | Joint Board/Council meeting | ||
Dinner | TBC | ||
Tuesday, Sept 13 | 09:00–13:00, break at ~10:45 | Full Council meeting | Armstrong Building in G.09.KLLT |
Present:
- Syd Bauman (SB, except on Mon from 16:15 to 17:05)
- Helena Bermúdez Sabel (HBS)
- Elisa Beshero-Bondar (EBB, except on Mon from 16:15 to 17:05)
- Elli Bleeker (EB, except on Tue)
- Hugh Cayless (HC)
- Martin Holmes (MH, as representative for Janelle Jenstad)
- Martina Scholger (MS)
- Sabine Seifert (SS)
- Peter Stadler (PS)
- Magdalena Turska (MT)
- Raff Viglianti (RV, except on Tue)
- Patricia O Connor (TOC, invited for the Monday morning session)
- Nicholas Laiacona (NL, invited for Monday morning session)
Apologies:
- Janelle Jenstad (JJ)
Council Members running workshops
- RV is busy on Tuesday (EB will be attending his event)
- EBB is busy on Monday from 16:15 to 17:05 (SB will join her)
SUNDAY, September 11
> Morning session (9:30–12:30)
>> Approval of the agenda
>> Topics for Board consideration
- Mailing lists
- Moving TEI-L (et al.) from Brown to Huma-Num.
- RV: Is Paderborn an option as well? They run the MEI ones. For archiving the TEI-L as HTML we could ask the Humanist Discussion Group for advice.
- Purchase of new mailing list services?
- HC: notes that there is less discussion on the TEI-Council List because most discussion happens on the Github issues.
- SB: There are ~17 lists on LISTSERV at Brown, most of which are no longer active.
- Anticipate problems with change of list names, inviting members (and losing invitations)
- Maintaining a consistent archive back to 1990 would be nice
- One of the only archives running that long in digital humanities
- Make the old archive a StaticSearch HTML project via Endings
- How do we organize the archive? Per creator, per thread… This makes a project in and by itself.
- Let’s figure out what the Humanist list does?
- https://dhhumanist.org/search.html
- They have a searchable archive online
- We figured out that this isn’t quite a full mailing list, it’s a distribution list and it seems to have a lot of custom code. So, it’s not for us.
- Answer from Laurent on migration of mailing lists to Huma-Num: “I have checked with them and they actually lack competence/capacity on the subject at present (they have opened a position to hire someone on the mailing infrastructure and hope to get better in the future). If the board is ready to pay, we need to find a freelancer on the issue.”
- Moving TEI-L (et al.) from Brown to Huma-Num.
- Slack
- Slack’s policy is that messages disappear after 90 days if we don’t pay for it, which means that we will lose our history if we don’t preserve it. If we keep it as an informal chat, this should be okay.
- Look into getting Slack for free (they managed to do that for e-editiones).
- Making a #public Slack channel available would be helpful to TEI users who aren't used to TEI email listserv culture.
- Slack’s policy is that messages disappear after 90 days if we don’t pay for it, which means that we will lose our history if we don’t preserve it. If we keep it as an informal chat, this should be okay.
- Discuss with Board whether we can still afford the two F2F meetings or if we should scale back to just one and do the other as a series of VF2F
- General Council preference for physical F2F
- Discuss with Board whether we still host an Annual Conference and Membership meeting
- Suggestion to host General Meeting over Zoom to make it available to members/public?
>> Invite potential Council members to the current F2F meeting
- Invite those who are here in Newcastle
>> Council’s report at annual general meeting
- ATOP
- Next release
- <gender> (round of feedback)
- nested <ab>s
- OxGarage / TEIGarage / MEIGarage
- CMC (expected in early next year)
- Social aspects of Council work during COVID-19
>> Tasks to takeover from PS
- PS will continue to run Jenkins services at Paderborn.
- He will still be part of the Stylesheets meetings and the CMC working group.
- Following in Martin Holmes’s example of remaining actively connected with the Council.
- PS will reassign some tickets.
- Docker-related stuff is well documented; much of it is automated through GitHub Actions. Workflows are in a .yml file which is relatively straightforward.
- PS will stay on Council’s e-mail list, infrastructure and CMC groups.
>> Moving from OxGarage to TEIGarage
- Report from PS
- Current status
- The monolithic OxGarage repo has been split up into various repos, facilitating maintenance and development of other “Garages”.
- There’s a new TEIGarage repo (under the TEIC organization at GitHub) that serves as a wrapper and main builder for the TEIGarage.
- The TEIGarage client application has been tentatively modified to show the new status; see the demo deployment at http://teigarage.tei-c.de.
- The new TEIGarage features many updates of libraries and dependencies, security fixes, and other improvements and is ready to be rolled out.
- TEI and MEI now have multiple “Garages” that can be used together
- TEIGarage is the main entry point.
- Actions to be approved by the Council
- Deploy TEIGarage at http://teigarage.tei-c.org and http://oxgarage.tei-c.org (i.e. no redirect, but OxGarage becomes an alias for TEIGarage).
- Move tickets from OxGarage repo to appropriate new repo(s).
- Place note on OxGarage repo.
- Archive OxGarage repo.
- Place note on OxGarage Docker repo.
>> ROMA
- RV contemplates removing beta
- This means: http://romabeta.tei-c.org becomes http://roma.tei-c.org and http://roma.tei-c.org becomes http://romaclassic.tei-c.org.
- Before removing beta, RV wants to finish its internationalization in the interface so it matches the original Roma
- Action on RV: December deadline for internationalization.
- Try crowdsourcing it, following TEI Publisher’s example.
- RV does have volunteers for covering French, Spanish, Italian, and German.
- Anything old Roma does that new Roma can’t?
- Support for RelaxNG (maybe not necessary for Roma, since it's mainly for producing new ODDs in Pure ODD).
- Help from people knowing JavaScript / React would be appreciated, RV thinks about students of his
- People involved would bridge JS and XML communities: these are unusual!
>> CMC
- October next meeting with CMC, then pass a draft chapter on to Council in ~November.
- It is planned to include it into the 2023 spring release.
>> Documentation
- Documentation is in different places – Wiki, Wordpress, documentation repo, Google drive, TCW – and some of it is out of date.
- A Task Force or subgroup effort is needed
- Take a moment to review what needs to be in the documentation repo; what's missing and needs to be moved there.
- Research old nomenclature system, and make a new system for documentation.
- Council is in agreement of using the documentation repo.
- Discard the old wikis for the Council’s documentation.
- Start right off during this F2F in a small group.
- Action on HC to update the GitHub Action to publish from the Documentation repo again.
- Should all our TCW documentation be written in TEI?
- Documentation repo supports both TEI and markdown, they can be made to look more or less the same.
- SB has been tinkering with publishing examples via XSLT.
- Should we use Guidelines <egXML>?
- However we do this, it must have one XSLT for transforming TCW TEI.
- One consistent TEI URL for all the documentation published from GitHub pages.
> Afternoon session (14:00–17:30)
>> Preparation for the next release
- Timeline
- Refridge = 11 Oct
- Freeze = 20 Oct
- Release = 25 Oct
- Features (issues) that we want to have in the next release:
>> Housekeeping
- Best to delete branches when they have been merged to dev.
- Stale release branches:
- On a new release, delete the release branches from past releases except the last one.
>> Review of Guidelines Issues
MONDAY, September 12
> Morning session (09:30–13:00)
>> Invited guest: TOC and NL
- Those who ran for TEI Council and are present in Newcastle were invited to attend Monday morning’s meeting to get a sense of the Council’s work.
>> Discussion and review of Guidelines Issues
- Discussion of Guidelines issues (break out sessions).
- Review of Guidelines issues with the whole group.
> Afternoon session (14:30–17:30)
>> ATOP report:
- ATOP (Another TEI ODD Processor)
- Repo: https://github.com/TEIC/atop
- Meeting notes: https://github.com/TEIC/atop/wiki/Meeting-notes
- Terminology: https://github.com/TEIC/atop/wiki/Terminology
- Schematron for our own code: https://github.com/TEIC/atop/blob/dev/Schemas/atop_xslt.sch
- ATOP tickets on TEI: https://github.com/TEIC/TEI/issues?q=is%3Aissue+is%3Aopen+atop
- Intention of ATOP
- Providing a processor that reads a customization ODD and a base ODD and produces an RNG + Schematron schema.
- ATOP would not replace all the Stylesheets (not make epub, etc.)
- ATOP is only to produce RNG and ISO-Schematron schemas.
- ATOP group meets once per week and gets work done in between
- Emphasis on strategizing HOW to do the work first.
- Thinking about inputs/outputs before they write any XSLT.
- Writing rules or “guardrails” for writing: consistent naming of files and variables, always using `@as` to type values. Try to make it easier to deduce what rules are handling particular actions.
- Problem: Pure ODD (and ODDs generally) are underspecified.
- They’re starting from the end: The last step of the process would be to produce a pruned localized ODD. Take the last output ODD and “transpile” it to RNG. The group is working on “transpiling”.
- Validity testing at every stage: Files produced in intermediate stages need to be valid.
- Start by combining base + customization ODD to create a "derived ODD".
- Discussion:
- Why is it important to work on the PLODD (Pruned Localized ODD) in the last step?
- Not using the term ”compiled ODD” because that contains the fuzzy baggage of the current Stylesheets. This is really different/more precise.
- PLODD doesn’t need to enter general community terminology; it’s for developers / the Council.
- Need a better path to produce PLODDs for development (currently working with sample project ODDs we’ve sent to help ATOP).
- Good that ATOP might refine/improve/specify the way we handle classes.
- What Council can do to help: keep an eye out on the tickets that the ATOP group will open (there is now also an ATOP label).
- Why is it important to work on the PLODD (Pruned Localized ODD) in the last step?
>> Stylesheets issues
- add @classpathref to common/teianttasks.xml #544
- already fixed and closed with PR https://github.com/TEIC/Stylesheets/pull/550
>> Discussion of Guidlines issues
- Continue plenary discussion of Guidelines issues, starting with #2247
>> i18n report
- HC reports on the Spec Translator.
- We should add more translations of the interface to https://github.com/TEIC/TEI/tree/dev/I18N/specTranslator.xml
> Board/Council meeting (17:30–18:30)
TUESDAY, September 13
> Morning session (9:00–13:00)
>> Discussion of Guidelines issues
- Continue plenary discussion of Guidelines issues, ending with #2295
Guidelines issues from SVF2F meeting in October 2021
Issues from the October 2021 meeting discussed by group B (European Group: MS, PS, MT, HBS) but on which no final decision was by the plenary.
#2136 | B | Use PureODD inside attribute lists | Subgroup recommends to deprecate @org on <attList> and use schematron rules instead. A few elements use <attList org=""> at the moment, e.g. <relation>. These would have to be re-written. SB: There is no comment on the ticket to this effect, so I am commenting here. I think this [using Schematron instead] is a terrible idea. One can express this (alternation of attributes) in RELAX NG, XML Schema, and even in ODD (except that it does not work in classes). There is no reason it should not remain expressible in ODD. 2022-09-11: SB left a comment in GitHub; issue closed, Stylesheets issue reopened |
---|
Guidelines issues from SVF2F meeting in April 2022
Issues from the SVF2F meeting in April 2022 discussed by group B (European Group: MS, PS, MT, HBS) but on which no final decision was made by the plenary. Group A: (HC), EBB, JJ, SB, RV
Group B: PS, HBS, MS, SS, EB
No. | Group | Title | Comment |
---|---|---|---|
#2137 | B | bookmark links in examples pages have no mouse-over text | Subgroup proposes to 1) add @rel="bookmark" and @aria-label on HTML output <a>. Consider opening a new issue for citation recommendation (issue with this is which link should be in the citation recommendation, the current release or stable link to the Vault). MT: Discuss issues arising from the request to offer citation buttons / bookmarks: tension between human readable and significant citation, e.g. TEI Guidelines, Reference for element <abbr>, Example 3 vs using a generated example id, direct bookmark link; latest vs fixed version (permalink) HC: Could we solve the citation problem (that the example id changes every version) by redirecting /latest/ to the current version? |
#2140 | B | Example needed to model attList for delimiting alternative groupings of attributes | Subgroup thinks this is great and should be added to the Guidelines after the Stylesheets have been prepared to support both the HTML output and the overriding of @type & @subtype as mentioned on the ticket. For the HTML output there’s already a ticket but for the overriding we need one. 2022-09-11: green, EBB will provide a reduced example |
#2144 | B | wrong attribution for example | Subgroup proposes (1) to change the whitespace to a hyphen; and (2) to add the same example with @ref instead of @key plus URL as value. 2022-09-11:SB will come up with an improved example |
#2190 | Should we revise datatypes related to sex and gender? | This is related to issue #2189: Create a gender element which is yellow and green 2022-09-11:CLOSED with all the action on gender branch. | |
#2213 | att.datatable.custom is under-documented in the Guidelines | This issue will be discussed on Saturday in the full Council session Where we introduced @datingPoint in the prose of the Guidelines (with ref to <calendar> element isn't helpful yet. 2022-09-11: EB and MH will come up with an example. Work is proceeding on this branch: https://github.com/TEIC/TEI/tree/issue-2213 |
Guidelines pull requests
No. | Group | Title | Comment |
---|---|---|---|
#2245 | Translation from CarmendeSantiago/TEI | Review HBS | |
#2281 | Translation from knagasaki/TEI | Review with MH, but probably ready to pull in | |
#2294 | Translation from knagasaki/TEI | Review with MH, but probably ready to pull in | |
#2320 | Translation from dh-miami/TEI | Review HBS | |
#2321 | Translation from joloor2/TEI | Review HBS | |
#2323 | Translation from casanso/TEI | Review HBS | |
#2328 | rename unboundedInt to unboundedCount | Review EBB and EB |
Guidelines issues
Group A: HB, EBB, HC, RV, NL Group B: SB, MT, TOC, PS
Group C: MH, EB, MS, SS
—-
Group D: SB, HB, SS
Group E: MT, MH, EBB
Group F: HC, MS, PS
No. | Group | Comment | |
---|---|---|---|
#2215 | A | att.pointing for <app>? | Subgroup: There’s no need to do this. Close won’t-fix. Maybe consider tweaking the note on @from. Council discussion: Green for EBB to tweak note and provide a simple example on the Spec page. |
#2216 | B | Example in rhyme.xml looks weird | Assigned to JJ to get in touch with Christian Wittern. |
#2221 | C | Why doesn't divGen have the same content model as div? | Subgroup: <divGen> is not supposed to have any content at all: it is supposed to be empty. So technically it should not contain <head> either, but in view of the Birnbaum doctrine we cannot make its data model empty. We should just close the ticket. Ticket is closed. |
#2222 | A | tagdoc for egXML speaks of attr in TEI namespace | Subgroup is repairing this on the spot. Error appears on the <egXML> spec, in the example. “used in the TEI namespace” was removed and the verb now agrees with the subject. Ticket is closed. |
#2225 | B | missing space | Leave for JJ - add space after or before <cl> and surround the example with <l> because it is verse (hence the uppercase T in “They”). The same problem occurs in the following example (which is in French). Green for JJ to fix. |
#2227 | C | Update ISOCat reference to DatCatInfo | MS: there is a related issue – I hope that MH can help with this Does login for https://datcatinfo.net/ work for everybody? It seems that attempts to access actual content in datcatinfo.net require logins, so we can’t link there. Linking directly to terms prompts login. Council is not in favor of using DatCatInfo. Reach out to LingSIG and Piotr Banski to come up with some wording to indicate the need to refer to a standard (and also to suggest the standard, if there is one). We need to remove all links to ISOCat anyway. |
#2228 | A | figure element in model.titlepagePart class? | Subgroup: Wordsmithing required to correct the false impression that <figure> is a member of model.titlePart. Subgroup is checking in this change now. Closed. |
#2242 | B | Another lg content model deficiency | Subgroup discussed several options: a) allow for <supplied> since it’s already allowed within <ellipsis>; or b) do not allow for <supplied> since it allows for too many elements not originally allowed within <lg>; or c) propose a new element <suppliedSpan> that would allow the editors to supply structural information (like lines) without allowing any further elements; d) make model.pPart.transcriptional part of the <lg> content model (suggested by RV; see below). Council discussion: If we go with a), provide strong guiding text in the Guidelines: What goes in <supplied> should be what belongs in <lg>.RV suggests we can add model.pPart.transcriptional to <lg>’s content model. This gets approval. |
#2246 | C | att.spanning value targeting an external document | Subgroup checked the current schematron rule in att.spanning.xml and, following HC’s suggestion to change it, we suggest the following: assert test="not(starts-with(@spanTo, '#')) or(id(substring(@spanTo,2)) and following::*[@xml:id=substring(current()/@spanTo,2)])" This change requires testing of course. Green for MT. |
#2247 | A | <handShift/> should be a member of model.global | Subgroup thinks `@hand` should suffice, and possibly that att.written might be expanded if someone needs more elements to be included. RV opens a new ticket to add a sentence to chapter 11, making the use of @hand and <handShift> more clear. |
#2248 | B | textLang should be able to contain bibl | Subgroup suggests to a) keep the current macro and add only <bibl>, or b) widen the content model to macro.specialPara (like other header elements). Council decides on b) and marks the issue as green. |
#2249 | C | Update data.temporal.iso | Subgroup: The first (and easiest) thing to do would be to simply remove the remark, which is what we did. The second action point would be to update to ISO8601:2019 and allow users to only use @when-iso, while still permitting the old expressions like @from-iso, etc. https://tei-c.org/release/doc/tei-p5-doc/en/html/ref-teidata.temporal.iso.html. It’s not clear to us that the semantics of @notBerfore-iso and @notAfter-iso are actually supported by ISO 8601’s Extended Date-Time Format; if they are, could someone who knows 8601 well explain how? |
#2251 | A | Need to update ODD transformation scenarios | Subgroup asks: was this fixed already? Check with MH then close. Closed. |
#2252 | B | Misuse of @xml:lang in an example for msPart | Mark as green |
#2254 | C | <measure> should be a member of att.ranging | Work in progress, SB and EB will come back to Council as soon as they have a proposal. |
#2258 | A | msIdentifier constraint should test node instead of its name; and does it make sense? | Subgroup thinks SB should make the Schematron test for the node rather than local-name() or name(). 1. We should improve the prose of the Schematron message. For example, this message (“An <msIdentifier> must contain either a repository or location.”) fires if we introduce an empty <collection>, when just adding contents to the element would make it valid. 2. The test shouldn’t force that the elements are not empty (as SB showed, examples with @key are perfectly valid) Be clear what we’re testing for, or whether there’s a need for it at all. This test might have been overly strict in the first place. Mark as green. |
#2261 | B | no need to specify scheme when deleting a constraint specification | Subgroup agrees that @scheme should not be required (and perhaps not allowed) if @mode is “delete”, but also wonders about a different solution (see ticket). Furthermore this issue raises the “what happens if you have multiple <constraintSpec>s in chained ODDs that have the same @ident?” question. Council agrees with the subgroup’s proposal, green for SB. |
#2262 | C | need examples of changing or deleting constraint specifications | Council discussion: we should provide an example that demonstrates and discusses deletion of any kind of spec (not just constraintSpec). Nothing too long. Discussion: Suggestion to create an example demonstrating how to work with att.combinable. mode="change" is much more complicated than mode="delete". But mode="change" is better exemplified. Green + Yellow for EB to work on examples for deletion and replacement. |
#2267 | A | detest target needs to be more comprehensible | SB added a note some days ago asking if this can be closed. Subgroup thinks, probably yes? Council: PR is merged, issue closed. |
#2271 | A | broken links on BIB.html | HC suggests checking for the broken links on the Internet archive and updating them. Subgroup greenlights. |
#2272 | A | various broken links to external resources | Subgroup thinks similar recommendation as for #2271 (check for where these external resources have moved). |
#2273 | D | Dictionaries:Homograph number is a property of the headword | SB suggests to ask @chr-emil: “Do you still want <hom> as a child of <form>, or have you decided to use some other method? If you still need it, we (Council) think we should put <hom> into model.formPart.” |
#2274 | E | example of decls= shows incorrect non-usage of default= | Subgroup thinks this is more complicated than SB’s ticket implies. Should the @xml:lang on <metDecl> or the elements effectively decide which one is default? Should we arbitrarily declare one default? Why must the Guidelines require a default? Default should be for guiding the processing, but it may not be required if it’s following the language declared. The example already illustrates how to reference the rhyming pattern explicitly for a piece. |
#2275 | F | Nabble TEI-L Archive No Longer Exists | Fixed |
#2276 | D | shouldn’t the class= attribute of the attRef element be a name? | Subgroup made this GREEN for EB to implement. |
#2277 | E | Seeking examples for att.written on stage | MH has added an example on the ticket to get us started. JJ and EBB to work on this in a branch. |
#2279 | F | Constrain translatable elements in TEI ODDs | Almost done; duplicate French gloss is actually mislabeled Spanish; mark green |
#2282 | D | attributes of <attRef> | Subgroup thinks both attributes should be required. Council: GREEN to require both. <attList org="choice"> <attRef class="att.typed"/> <attRef class="att.datable"/> </attList> |
#2285 | E | more on <altIdent> | Subgroup believes that: For the ODD stage where RNG is being generated, there should only be a single <altIdent> at most. However, earlier in the processing chain, it is reasonable to have different <altIdent>s for different languages; it makes sense, for instance, to have Arabic <altIdent>s for convenience when working RTL, with another LTR language <altIdent> alongside it. So we think that the requirement should be that if you have multiple <altIdent>s, they must all have different @xml:lang values. The processor would then select the correct language <altIdent> before generating the PLODD (to use ATOP terminology) and then have no further decision to make when generating the RNG.On the issue of elements where <altIdent> can never end up in the schema at all, we see no reason to retain <altIdent>, and it would be clearer to deprecate and remove it. |
#2286 | F | errors in the generation of templates | Mark as green; ask SB about the current status. |
#2292 | D | Allow <listBibl> in <abstract> | Subgroup suggests to allow <listBibl> either in <abstract> or to add it to model.listLike (group B is partial to the latest if it doesn’t cause too many problems). Council agrees to SS’ proposal. GREEN. |
#2295 | E | Add an organism element | Subgroup thinks that rather than creating elements for more specific types of things, it would be better to create a more generic <entity> element, of which all the specifics we have (<person>, <org> etc.) are all syntactic sugar. This way, whatever your ontological preferences in dividing the world, you can use <entity type="organism"> or whatever. SB:+1 Council decision: Close this ticket and open a new one to propose <entity>, <listEntity>, and create a content model. Should there be a task force? YES Do not merge with #367, says PS <entity> can be used as a more generic and customizable mechanism when existing “ography” constructions don’t work. Issue closed, new issue #2341 opened. |
#2298 (continue with review in October 2022 meeting) | F | description vs gloss in @type of <divGen> | Mark as green; go ahead |
#2300 | D | restrict embedded transcription to sourceDoc / exclude text in zone and line as part of facsimile | Subgroup suggests marking it as green. |
#2303 | E | URLs of projects using TEI are not displayed on the individual project info pages | Subgroup inquires: where is the TEI underlying the projects page? And where is the XSLT that processes it? For some entries (probably older ones), it looks like some TEI elements (like <ptr>) are embedded in the HTML, while others are just HTML. The TEI needs to be cleaned out of the page. |
#2306 | F | tagdocs elements are available in silly contexts | Subgroup: that would be a breaking change and we’re not sure whether it’s worth the effort. Might make a case for an ATOP-specific application profile (customization)? Does SB remember why the membership in model.inter came about? |
#2314 | D | TEI example is old-formatted | Subgroup suggests marking it as green. |
#2315 | E | example example discusses a possible future feature | Subgroup agrees that changing the item is a good idea to encourage best practices. |
#2316 | F | <speaker> as content of <lem> | Subgroup: we’re not against it, but it seems too hard to implement (i.e. too much of a stretch for the content models of <lem> and <wit>); and for the currently provided example there are several workarounds in the comments. |
#2317 | D | <app> as sole content of a <sp> element | Subgroup thinks this should be allowed, but note that since <app> is a member of model.global.edit it is going to be very difficult (if not impossible) to do. <app> should have a warning informing encoders that it’s their responsibility that the contents of each <app>/<rdg> or <app>/<lem> is valid within the parent of the <app>. |
#2326 | E | constraints on <dataFacet> and @restriction should be explicit | PS has already solved and closed this. |
#2327 | F | teidata.unboundedInt should be named teidata.unboundedCount | Seems sensible. Subgroup thinks we should merge the PR and close. Do we need deprecation of teidata.unboundedInt before nuking it?Council: no, deprecation is not necessary. |
#2330 | D | schemaSpec should provide a mechanism for specifing Schematron query language binding | |
#2331 | E | bad link → consistent referencing needed to ISO 24611 | Subgroup suggests green for go to create a new bibliography entry and fix all references to point to it. |
#2332 | F | How are we to refer to an <egXML>? (Or <figure> or <table>?) | Subgroup: This should be addressed and added to TCW20. |