Ticket Triage

Kevin said he suspected Elli will join the call, so he suggested we postpone discussion of issue 20 till then.

Issue 34

Kevin said that James had recently added a commit to implement this. Kevin said he would review it after the call.

Paul noted that his group at the University of Michigan has used a <pb>s each time the the reader jumps pages, treating this as a marker of an event rather than evidence of a break at that point in the document. But he admitted that this is an unconventional approach and suggested we not bring this into the BPTL if the BPTL doesn't discuss this. Kevin agreed. [See later discussion on TEILIB-L.]

Issue 20

Since Elli had joined the call, Kevin asked if she wanted to discuss her most recent post to the ticket. She verified that the ticket was about the table inside the "Introduction" section, and she said that she wanted to update all "Display example" links that go to website homepages rather than to specific texts. Everyone agreed that she should do this.

Elli asked if we are committing to master branch or making pull requests. Kevin said that either is fine, but the advantage of a pull request is that it forces a second set of eyes to review changes. We agreed that this is especially important for changes to content models in the ODD (rather than simply to prose).

Issue 4

Elli said she would get back to this later this week.

Issue 5

Kevin asked Paul if he'd had time to review his proposed text. Paul said he had and that it all made sense. Kevin asked if anyone else would like to review before he commits. Hearing none, he said he would commit.

Issue 36

Kevin asked Paul if he's made any progress. He said he has begun writing up his notes but thought they might be better circulated in Google Docs rather than as a comment on the issue. Kevin agreed since this allows edits and discussion on a granular level, unlike in the GitHub issue comments. Elli suggested that he simply post a link to the Google Docs document as a comment on the issue.

Issue 14

After some group discussion, Paul suggested that you will have different needs for text input, quality control (QC), and output. After some discussion, we agreed that a project's needs could differ even for text input and QC, but we felt that recommending UTF-8 for output, without discussing use of entity references, makes sense. (While NCRs can be used in XML, software is liable to create or remove these, and they aren't a problem for preservation, so their presence doesn't matter. As for mnemonic entity references, it's unlikely people will use them since we believe they require that you use a DTD.

As for use of <g>, Kevin said he felt that this was a fairly niche need for library encoding projects—that if a project required use of <g>, it was probably more advanced than your average library-based encoding project, and the staff would have developed a customization without relying on the BPTL.

Paul added that it might be worth addressing the encoding of glyph variants: while <g> could be used to capture glyph variants not distinguished by Unicode, users of the BPTL should think twice about whether such a distinction is really worth capturing if Unicode didn't consider these variants to be separate characters. In other words, there might be more to be gained by using Unicode as is than by capturing a fine distinction.

Elli recommended a new chapter of the P5 Guidelines, written largely by Martin Holmes, that addresses many of these matters. She suggested that we refer to this in any explanation that we add.

Kevin asked if anyone would like to draft text to be added to the General Recommendations section of the BPTL. No one volunteered, so he said he would draft something and add to the ticket.

Issue 17

Kevin summarize the issue, noting, as in the first comment on the issue, that some object on principle to a document claiming to conform to a particular schema because this something that should only be verified externally. In summarizing, he realized that it would also be good if we could specify which version of the BPTL a document conforms to.

Elli asked if we want to record (alleged) conformance or only aspiration of conformance.

Paul noted that at the University of Michigan, they use not only editorialDecl@n but also include a boilerplate statement inside a <p> within <editorialDecl> that names the BPTL and the encoding level.

Elli noted that <editorialDecl> is meant for discussion of editorial practice, not which schema is used.

Kevin suggested <tagsDecl>, but Paul noted that despite its definition, this element is meant for a specific purpose not like what we need it for.

Kevin asked Elli and Stefanie to investigate and bring a proposal back to the group. He said that he could only assign to one person in GitHub [actually, you can assign to more than one], so he would assign to Elli [but was actually able to assign to both].

Next meeting

Kevin said that since the first Monday of next month is a holiday in the US we would meet the following Monday (September 12). He said he will send a reminder as usual.