TEIWiki - User contributions [en]

TEI-Council-FAQ

2023-09-19T14:20:28Z

Hcayless: /* What funding is available for Council Activities? And how do I get reimbursed? */

So you have some questions about how the [[Council|TEI Technical Council]] works? This page has been set up to answer questions that new council members (or other curious parties) may have.

== Overview ==

=== How does the Council do its work? ===

By every means possible. These include monthly remote meetings, email, widely circulated discussion documents, and public debate in other contexts such as TEI-L and GitHub issues. The Council meets face to face twice a year (usually one of those meetings concurrent with the TEI Annual Meeting), and many more times than that virtually. Sub-groups of Council will often form around particularly large or complex issues and may meet separately to deal with them.

=== And what work does it do? ===

You should probably review the recent official work of the Council by reading the last few sets of minutes: http://www.tei-c.org/Council/ has an index page which links to them all (when we remember to update it). The minutes record topics discussed and responsibilities allocated at the Council level. Of course many Council members are also active in subgroups (formal or informal) of the Council or SIGs, which may be documented elsewhere as well.

Generally, things in Council work like this:

# A bug report or feature request is reported by anyone at [https://github.com/TEIC/ GitHub] for the [https://github.com/TEIC/TEI/issues Guidelines] or [https://github.com/TEIC/Stylesheets/issues Stylesheets].
# Sometimes others notice the ticket and comment on it.
# Sometimes a Council member may make an executive decision on the ticket. If it's a corrigible error or bug, we can just fix it in the appropriate ODD file(s) (also in GitHub). If it is not a real issue, sometimes the ticket will just be closed. If you do not have developer access on GitHub you'll ask to be added to the Council team there. Otherwise, it's discussed either by email on the Council mailing list or at a Council meeting (conference call or in-person meeting). Comments are recorded in the ticket reflecting the decision reached, and changes are made in GitHub by a member of the Council sometime thereafter.
# The change shows up on tei-c.org after the next TEI "release", which happens about two or three times a year.

However, Council does sometimes consider lengthy proposals circulated to Council outside of GitHub and vote on them as packages, with the changes grouped together in a sensible way so they can be considered in smaller packages, or with the changes listed individually.

=== And what is its scope? ===

The Council's primary responsibility is to act as technical watchdog for the intellectual content of the TEI Guidelines. That is to say: it has the final say in just about every aspect of the TEI encoding scheme -- what elements exist in it, what they are called, how they should be used.

=== How do I join the TEI Council mailing list? ===

We have had the practice on the Council so far that elected members get added immediately to the list (and to the telecon, if there is one), with every right to participate, while outgoing members stay on until the end of their term. To join or discuss any problems using the list contact the [mailto:tei-council-owner@lists.tei-c.org TEI Council mailing list owner], currently this is Luis Meneses (Victoria). There is also a joint Board/Council mailing list to which you should be added as well.

=== Why are some people on the Council email list or attending Council meetings even though they are not on the list of elected members? ===

In addition to the members of the Council, the chair of the TEI Technical Council may invite others not elected to the Council to meetings (e.g. to speak to a particular issue). Historically the Council often invited a representative of the Board to the Council mailing list and meetings. The TEI-C Webmaster (currently Luis Meneses) are also on the mailing lists.

=== What are the various job roles on the TEI Council? ===

==== TEI Technical Council Member ====
A TEI Technical Council Member is expected to participate in all aspects of Council work. This means that they should learn how the TEI infrastructure is organised and [http://www.tei-c.org/Activities/Council/Working/tcw20.xml how to edit the TEI Guidelines], asking on the Council list any questions they might have. They will be expected to come to face-to-face ("f2f") meetings (often two per year) and participate in a couple other teleconferences per year. They will be assigned (or take) feature requests/bugs on [https://github.com/TEIC the TEI Consortium's GitHub site], for which they will be in charge of encouraging discussion, reporting on the issue to Council, and eventually implementing (or ensuring implementation) of the resulting decision. A TEI Technical Council Member is expected to participate in the maintenance and development of the TEI Guidelines and related outputs. Some elected TEI Council members focus more on particular aspects of the infrastructure or stylesheets as part of the contribution to the Council. Council members should always act to represent what they believe are the opinions and best interest of the community that has elected them.

==== TEI Technical Council Chair ====
The TEI Technical Council Chair's role is to administrate and facilitate the work of the TEI Technical Council. If all of the Council are the elected servants of the community, then the Council Chair is the servant of the servants of the TEI (''Servus servorum TEI''). The duties of the Technical Council Chair include (in no particular order):
* ensuring the delivery and maintenance of the Guidelines
* arranging for Council members to actively participate in Council activities
* arranging and chairing the face-to-face meetings (in conjunction with the local organiser)
* arranging and chairing the teleconferences
* creating agendas for those meetings, and ensuring minutes are written and posted of them
* assigning tickets in [http://github.com/TEIC/ the TEIC Github organization]
* acting as SIG coordinator
* liaising for and reporting on Council activities at all Board meetings
* reflecting Council wishes in Board discussions
* acting as a public point of contact and responding to technical enquiries (messages to council@tei-c.org are forwarded to the Council Chair)
* announcing new releases of the Guidelines on the TEI-L mailing list
* ensuring the smooth running of the TEI Technical Council

The TEI Technical Council Chair is also a member of the Council, so has all the duties and obligations of being a council member as well.

==== Release Technician ====
The TEI Guidelines release process (see [http://www.tei-c.org/Activities/Council/Working/tcw22.xml tcw22: Building a TEI Release]) involves a single individual responsible for 'pushing the button' and completing the steps required to make a TEI Guidelines release live. This is not a standing position; instead, the responsibility rotates for every release in order to demystify the release process and spread the expertise beyond Oxford staff. Although we have documented the work in quite a detailed manner, it is a non-trivial process and involves a fair degree of work. A release technician is usually required to set aside a whole day for the release process since history teaches us that often the entire process needs to be re-run to correct last-minute errors.

==== TEI-C Webmaster and Assistant Webmaster ====

The TEI-C Webmaster and Assistant Webmaster are not officially part of the Council but may be added to the mailing lists at the discretion of the Council Chair. They are responsible for the smooth running of the TEI-C Website.

=== How is the TEI Technical Council Chair elected? ===

The [http://www.tei-c.org/About/bylaws.xml#body.1_div.3_div.3 Bylaws of the TEI-C] say that:
<blockquote>
The Chair of the Technical Council shall be elected by the voting Members of the TEI-C Technical Council from its membership and shall serve as the chief technical officer of the Consortium. If no Technical Council Member is able or willing to assume the chair, the Technical Council may request the Board of Directors to second one of its elected members to the role, or it may nominate a non-elected individual.
</blockquote>
This leaves it intentionally vague as to the precise process the TEI Technical Council will follow. For now there is vague consensus that they will do something like the following. Note that timeframes below are not intended to be rigid or precise, but rather to be suggestive.
# The new Technical Council Members will be added to the tei-council (and tei-board-council) mailing lists shortly after the members' meeting. Up until around the last last Friday in November those who are Council members for next year will consider whether they want to run to be Chair of the TEI Technical Council. The current Chair will facilitate this process by answering any questions about the post. Before that date those intending to stand should send a statement of some sort to the Council mailing list detailing why they think the council members should vote for them.
# On or around the first weekday of December if only one person is running then the Chair will announce this to the tei-council mailing list as an acclamation (and after a short period for objections, to the Board and TEI-L). If multiple people are running, then the Council Chair will appoint a "returning officer" who is not a member of the incoming Council (i.e., not a voter and thus at least a somewhat disinterested party). The returning officer will set up an electronic voting system with the names of the candidates. This should be a private election with no one able to determine who has voted for whom. E.g. if using opavote.org this should have the following settings:
## Results only shown at end
## Method: "Plurality/FPTP/SNTV" for 2 candidates, "Instant Runoff Voting" for 3 or more
## a single winner
## Ballot type: "choose one" for 2 candidates, "ranked enhanced" for 3 or more
## candidate order shuffled
# The returning officer should ensure the election runs for at least 4 days, preferably in early December, after announcing it on the tei-council mailing list (and distributing ballots depending on the system).
# The results will be announced publicly on the tei-council mailing list, and Council members given a brief chance to raise any objections with the election before the current Chair informs the Board and announces it more publicly on TEI-L.
# The new Chair assumes the role on 1 January. The current chair steps down on 31 December. The outgoing and incoming chairs should co-ordinate activities between the election and 1 January so as to ensure a smooth transition. (Remembering that the current Chair might be departing off council at the end of that year.) These dates and timescales can of course shift and are not meant to be set in stone.

== Terminology ==

=== What is a "corrigible error"? ===

This is a term that comes up in Council discussions and refers to an error or inconsistency in the Guidelines that can be fixed without requiring a deprecation period.

=== What was the War on Free-text-bearing Attribute Values? ===

The War on Free-text-bearing Attribute Values, also known as the War on Free-text-bearing Attributes and the War on Attributes for short, happened because some have felt that if attribute values don't have a datatype, they are more prone to abuse than if they did. So there has been an effort to give datatypes to as many attributes as possible. Some discussion of this with respect to @rend is available here: http://blogs.oucs.ox.ac.uk/jamesc/2011/12/01/rend-and-the-war-on-text-bearing-attributes/

=== What is the "Birnbaum doctrine"? ===

As expressed in [http://www.tei-c.org/Activities/Council/Working/tcw09.xml TCW09: Backward Compatibility and the Maintenance of the Text Encoding Initiative Guidelines], we should avoid breaking backward compatibility and only do so after serious consideration. It does not mean that we cannot break backwards compatibility, just that we've agreed a set of steps to take when we do so. Our deprecation policy supersedes some of this.

=== In what ways will Council break backwards compatibility? ===

For an egregious error, we might actually change a content model immediately. More often, we will survey the community on TEI-L before doing so, and we might [[Practices no longer recommended or now deprecated|deprecate]].

=== What is the "Durand Conundrum"? ===

The "Durand Conundrum" was suggested by David G. Durand concerning the TEI's decision to use the [[ODD | TEI ODD]] meta-schema language rather than just one of the existing schema languages. Given that we decided to use our own language, why use RelaxNG as part of that language for describing content models? Generally, the consensus is that [[ODD | TEI ODD]] gives us greater power and flexibility than any individual schema language can do in that we can model things that those schema languages are currently unable to cope with. TEI ODD gives the ability for a single document to produce both documentation and schema since these are inherently interlinked. It also keeps the TEI honest, in requiring it to use its own system to document schemas. [[ODD | TEI ODD]] does currently have some problems, a few of which are detailed at [[ODD-dev]] and successive revisions of TEI ODD are intended to solve some of these. Increasingly [[ODD#Future_plans:_.22Pure_ODD.22|the work on Pure ODD elements for content models and datatypes]] has cut the gordian knot of this problem.

=== What does "no magic" mean? ===

'Magic' in the sense sometimes used in Council discussion refers to pre-existing or special knowledge required to process something. For example, it was only by 'magic' that a TEI ODD processor would know to add attributes from the att.global attribute class to elements until this was changed to make all element specifications have to explicitly claim membership in this class if they wanted the global attributes. Knowing to add them was 'magic', and in general it is better if any requirements or understood knowledge is explicitly documented. While some 'magic' of understood conventions or processing will always remain in complex technical systems, the Council strives to at very least enable the possibility of documenting the underlying rules when it discovers them. James Cummings has been a fervent proponent of the removal of any understood 'magic' rules from the TEI.

=== What is a non-deterministic content model? ===

If you have a content model for <a>:

<pre>
b*, c?, b*
</pre>

and you have a document with:

<pre>
<a>

</a>
</pre>

then a parser can't tell whether the matches the first b* or the second b* in the content model. Thus, the content model itself is called “non-deterministic”. DTDs and W3C XML Schemas reject non-deterministic content models. Thus, if we were to create one in the TEI, validation with DTD and XSD would fail due to errors ''in the schema'', regardless of whether the instance document has an occurence that is non-deterministic or not.

=== What are Janus elements? ===

These are pairs of elements that are in a sense two sides of the same coin, such as orig and reg, corr and sic, abbr and expan.

=== What does it mean to say that elements tessellate? ===

This means that all textual content is included in exactly one instance of an element. For example, once you start using divs (numbered or unnumbered), all text thereafter must be inside of one of the divs: you can't start using p elements that are not wrapped in a div.

In the Guidelines this is sometimes referred to as end-to-end segmentation.

== Meetings ==

=== Where are the minutes of previous meetings? ===

Minutes are [http://www.tei-c.org/Activities/Council/Meetings/index.xml archived on the TEI website]. Interim states of minutes may at times live in this wiki, Google Docs, or elsewhere.

=== How are the Council meetings held? ===

The Council usually makes use of Google Meet/Hangouts for their meetings. The meeting link will be in the agenda and/or sent out on the Council list before the meeting.

=== What funding is available for Council Activities? And how do I get reimbursed? ===

The TEI funds the participation of the council members in the meetings.

If the council has a meeting, then the council members' travel, hotel, etc. will be reimbursed with proper receipts. The TEI reimburses all reasonable expenses in keeping with standard practice at most universities and granting agencies. We cover meals, travel, lodging, and other common daily travel expenses. Airfare should be economy class and direct return, unless otherwise arranged with the Treasurer prior to your trip. If you have questions about reimbursement procedures, including what is reimbursable, please email Hugh Cayless, the TEI treasurer, at philomousos AT gmail.com.

Use the TEI Travel expense form available here: https://tei-c.org/tei_travel_form/ '''Expense forms should be submitted within 1 month of the end of the meeting.'''

== How we get work done ==

=== I have something to say about a GitHub Feature Request or Bug: Should I comment on the issue or the TEI Council mailing list? ===

There is no hard-and-fast policy on this. The mailing list is a better place for ongoing discussions where people are arguing back and forth during decision making. The GitHub tracker is the appropriate place to record opinions, positions, and decisions for posterity, especially if such would help a) whoever is implementing the decisions recorded in the ticket, b) anyone revisiting this decision later to retrace the thinking. The [http://lists.tei-c.org/pipermail/tei-council/ TEI Council mailing list archives] are public, so if substantial discussion has taken place there (or indeed on TEI-L), this can also be linked to from the ticket.

=== When is discussion on an element or topic "closed" and how do I know? ===

Any topic can be revisited at any point, even in the published guidelines, through posting a feature request on GitHub. Council-specific issues should be raised on the council mailing list, after having reviewed any previous discussion on the topic in the [http://lists.tei-c.org/pipermail/tei-council/ tei-council mailing list archives].

=== How can I find out about every time a ticket is created or commented on? ===

Each repository has a "watch" control, which is to be found on the top right or the repo's GitHub page, below the navigation bar. This control lets you manage notifications in various ways.

=== How are tickets assigned in GitHub? ===
All members of Council are made part of the Council Team on the GitHub TEIC Organisation and meant to take an active role in the development and maintenance of the TEI Guidelines. This means that they have write access to the TEI Guidelines Github Repository, and tickets can be assigned to them in the ticket trackers. They can also update and modify tickets. This means that Council members are free to 'take' tickets which they wish to oversee. Other Council members can also 'give' tickets to each other if they think someone particularly suited to overseeing a particular ticket. (However, usually they should have the Council member's permission to do so.) On a regular basis the Council Chair will assign tickets to Council members, if a ticket gets assigned to them that they don't want to do they should tell the Chair and/or ask other Council members to swap.

=== What do the issue labels mean? ===

* 'Status: Blocked' means that the issue cannot be progressed because it requires either that another issue be completed first or that more information is needed from the reporter or a third party.

* 'Status: Needs Discussion' means that the issue has not been talked about enough yet to resolve it. New issues nearly always go into this status first. When Council has face-to-face meetings, these are usually the issues we target first.

* 'Status: Go' means that the ticket has been discussed, there is general consensus on what the correct thing to do is, and it has been assigned for someone to ensure its implementation.

* Other labels should be self-explanatory, and are sometimes created as needed to group tickets for various purposes.

=== How does a TEI release happen? ===

The process of making a release is documented at http://www.tei-c.org/Activities/Council/Working/tcw22.xml

== Working in GitHub ==

=== How do I edit the TEI Guidelines? ===

Editing the TEI Guidelines is a complex process and the Council has produced a document http://www.tei-c.org/Activities/Council/Working/tcw20.xml covering the logical and physical layout of the Guidelines, stylistic notes, how to make a change to the Guidelines (it requires [[TEI-Council-FAQ#How_do_I_use_GitHub.3F|using subversion]], building a release, and a reference section of useful information). If any information you need isn't in this document, ask on the Council list and get someone to update it!

=== How can I find out about every time a change is made in the TEI GitHub repository? ===
# Go to https://github.com/TEIC/
# Make sure you are logged in and
# go into each repository you are interested in and 'watch' them.

=== How do I use GitHub? ===
The TEI stores its working files in repositories in the [https://github.com/TEIC TEIC GitHub Organization]. See the [http://www.tei-c.org/guidelines/p5/using-the-tei-github-repository/ instructions]. Write access is reserved for those who are on the TEI Council or TEI Contributors teams. Any Council member should be able to add you to the Council team.

=== What should I put in a GitHub commit message? ===

It is beneficial to all those looking at the TEI GitHub repository if commit messages are clear and detailed. This is especially true when trying to revert changes made by yourself or others to solve problems. A good commit message will include:
* a subject line less than 72 characters long (which may be the whole message if no more is needed)
* an explanation to a useful level of detail about what you did
* a mention of why this is being done
* the GitHub issue numbers (or urls) that relate to the change if applicable
* an explanation of whether this change is completing the work described or one step towards doing so.

== TEI website ==

=== I want to add a document to add meeting minutes, reports, or working papers to the TEI-C website. How do I do that? ===

The TEI has a longstanding naming convention for files that consists of:

# a short alphabetical abbreviation for a committee (such as "tc" for "Technical Council")
# a one-letter abbreviation for minutes ("m"), reports ("r"), or working papers ("w")
# a two-digit number for the document with a committee series, numbered sequentially (e.g., "tcw01" is the first working paper from the Technical Council, "tcm05" is the fifth minutes from the Technical Council, etc.)

These documents currently reside in the [https://github.com/TEIC/Documentation Documentation] repo on GitHub.

=== How do I get access to the Google Analytics Data for www.tei-c.org? ===

Email the TEI-C webmaster: web@tei-c.org.

== Miscellaneous ==

=== Why do some elements have @type and others do not? ===

The TEI has avoided adding @type globally to elements because its availability is thought to invite tag or attribute abuse. In order for a request to add @type to an element to be considered for prolonged discussion and argument the TEI Technical Council has a standing principle that an element should be both repeatable and have obvious different classifications that apply to it. If such a request is approved then the preferred method is to make the element a member of the att.typed class (because if you can have @type, you can also have sub-types and thus need @subtype). If a closed or suggested value list, or different description is needed, this should then be provided as a local modification to the attributes inherited from att.typed.

== I have a question! ==

Then add it just above this one or email someone on the council or the council list reminding them of the existence of this wiki page when you ask your question.

[[Category:Council]]

TEI-Council-FAQ

2019-10-08T15:47:16Z

Hcayless: /* Terminology */

So you have some questions about how the [[Council|TEI Technical Council]] works? This page has been set up to answer questions that new council members (or other curious parties) may have.

== Overview ==

=== How does the Council do its work? ===

By every means possible. These include monthly remote meetings, email, widely circulated discussion documents, and public debate in other contexts such as TEI-L and GitHub issues. The Council meets face to face twice a year (usually one of those meetings concurrent with the TEI Annual Meeting), and many more times than that virtually. Sub-groups of Council will often form around particularly large or complex issues and may meet separately to deal with them.

=== And what work does it do? ===

You should probably review the recent official work of the Council by reading the last few sets of minutes: http://www.tei-c.org/Council/ has an index page which links to them all (when we remember to update it). The minutes record topics discussed and responsibilities allocated at the Council level. Of course many Council members are also active in subgroups (formal or informal) of the Council or SIGs, which may be documented elsewhere as well.

Generally, things in Council work like this:

# A bug report or feature request is reported by anyone at [https://github.com/TEIC/ GitHub] for the [https://github.com/TEIC/TEI/issues Guidelines] or [https://github.com/TEIC/Stylesheets/issues Stylesheets].
# Sometimes others notice the ticket and comment on it.
# Sometimes a Council member may make an executive decision on the ticket. If it's a corrigible error or bug, we can just fix it in the appropriate ODD file(s) (also in GitHub). If it is not a real issue, sometimes the ticket will just be closed. If you do not have developer access on GitHub you'll to ask to be added to the Council team there. Otherwise, it's discussed either by email on the Council mailing list or at a Council meeting (conference call or in-person meeting). Comments are recorded in the ticket reflecting the decision reached, and changes are made in GitHub by a member of the Council sometime thereafter.
# The change shows up on tei-c.org after the next TEI "release", which happens about two or three times a year.

However, Council does sometimes consider lengthy proposals circulated to Council outside of GitHub and vote on them as packages, with the changes grouped together in a sensible way so they can be considered in smaller packages, or with the changes listed individually.

=== And what is its scope? ===

The Council's primary responsibility is to act as technical watchdog for the intellectual content of the TEI Guidelines. That is to say: it has the final say in just about every aspect of the TEI encoding scheme -- what elements exist in it, what they are called, how they should be used.

=== How do I join the TEI Council mailing list? ===

We have had the practice on the Council so far that elected members get added immediately to the list (and to the telecon, if there is one), with every right to participate, while outgoing members stay on until the end of their term. To join or discuss any problems using the list contact the [mailto:tei-council-owner@lists.tei-c.org TEI Council mailing list owner], currently this is Luis Meneses (Victoria). There is also a joint Board/Council mailing list to which you should be added as well.

=== Why are some people on the Council email list or attending Council meetings even though they are not on the list of elected members? ===

In addition to the members of the Council, the chair of the TEI Technical Council may invite others not elected to the Council to meetings (e.g. to speak to a particular issue). Historically the Council often invited a representative of the Board to the Council mailing list and meetings. The TEI-C Webmaster (currently Luis Meneses) are also on the mailing lists.

=== What are the various job roles on the TEI Council? ===

==== TEI Technical Council Member ====
A TEI Technical Council Member is expected to participate in all aspects of Council work. This means that they should learn how the TEI infrastructure is organised and [http://www.tei-c.org/Activities/Council/Working/tcw20.xml how to edit the TEI Guidelines], asking on the Council list any questions they might have. They will be expected to come to face-to-face ("f2f") meetings (often two per year) and participate in a couple other teleconferences per year. They will be assigned (or take) feature requests/bugs on [https://github.com/TEIC the TEI Consortium's GitHub site], for which they will be in charge of encouraging discussion, reporting on the issue to Council, and eventually implementing (or ensuring implementation) of the resulting decision. A TEI Technical Council Member is expected to participate in the maintenance and development of the TEI Guidelines and related outputs. Some elected TEI Council members focus more on particular aspects of the infrastructure or stylesheets as part of the contribution to the Council. Council members should always act to represent what they believe are the opinions and best interest of the community that has elected them.

==== TEI Technical Council Chair ====
The TEI Technical Council Chair's role is to administrate and facilitate the work of the TEI Technical Council. If all of the Council are the elected servants of the community, then the Council Chair is the servant of the servants of the TEI (''Servus servorum TEI''). The duties of the Technical Council Chair include (in no particular order):
* ensuring the delivery and maintenance of the Guidelines
* arranging for Council members to actively participate in Council activities
* arranging and chairing the face-to-face meetings (in conjunction with the local organiser)
* arranging and chairing the teleconferences
* creating agendas for those meetings, and ensuring minutes are written and posted of them
* assigning tickets in [http://github.com/TEIC/ the TEIC Github organization]
* acting as SIG coordinator
* liaising for and reporting on Council activities at all Board meetings
* reflecting Council wishes in Board discussions
* acting as a public point of contact and responding to technical enquiries (messages to council@tei-c.org are forwarded to the Council Chair)
* announcing new releases of the Guidelines on the TEI-L mailing list
* ensuring the smooth running of the TEI Technical Council

The TEI Technical Council Chair is also a member of the Council, so has all the duties and obligations of being a council member as well.

==== Release Technician ====
The TEI Guidelines release process (see [http://www.tei-c.org/Activities/Council/Working/tcw22.xml tcw22: Building a TEI Release]) involves a single individual responsible for 'pushing the button' and completing the steps required to make a TEI Guidelines release live. This is not a standing position; instead, the responsibility rotates for every release in order to demystify the release process and spread the expertise beyond Oxford staff. Although we have documented the work in quite a detailed manner, it is a non-trivial process and involves a fair degree of work. A release technician is usually required to set aside a whole day for the release process since history teaches us that often the entire process needs to be re-run to correct last-minute errors.

==== TEI-C Webmaster and Assistant Webmaster ====

The TEI-C Webmaster and Assistant Webmaster are not officially part of the Council but may be added to the mailing lists at the discretion of the Council Chair. They are responsible for the smooth running of the TEI-C Website.

=== How is the TEI Technical Council Chair elected? ===

The [http://www.tei-c.org/About/bylaws.xml#body.1_div.3_div.3 Bylaws of the TEI-C] say that:
<blockquote>
The Chair of the Technical Council shall be elected by the voting Members of the TEI-C Technical Council from its membership and shall serve as the chief technical officer of the Consortium. If no Technical Council Member is able or willing to assume the chair, the Technical Council may request the Board of Directors to second one of its elected members to the role, or it may nominate a non-elected individual.
</blockquote>
This leaves it intentionally vague as to the precise process the TEI Technical Council will follow. For now there is vague consensus that they will do something like the following. Note that timeframes below are not intended to be rigid or precise, but rather to be suggestive.
# The new Technical Council Members will be added to the tei-council (and tei-board-council) mailing lists shortly after the members' meeting. Up until around the last last Friday in November those who are Council members for next year will consider whether they want to run to be Chair of the TEI Technical Council. The current Chair will facilitate this process by answering any questions about the post. Before that date those intending to stand should send a statement of some sort to the Council mailing list detailing why they think the council members should vote for them.
# On or around the first weekday of December if only one person is running then the Chair will announce this to the tei-council mailing list as an acclamation (and after a short period for objections, to the Board and TEI-L). If multiple people are running, then the Council Chair will appoint a "returning officer" who is not a member of the incoming Council (i.e., not a voter and thus at least a somewhat disinterested party). The returning officer will set up an electronic voting system with the names of the candidates. This should be a private election with no one able to determine who has voted for whom. E.g. if using opavote.org this should have the following settings:
## Results only shown at end
## Method: "Plurality/FPTP/SNTV" for 2 candidates, "Instant Runoff Voting" for 3 or more
## a single winner
## Ballot type: "choose one" for 2 candidates, "ranked enhanced" for 3 or more
## candidate order shuffled
# The returning officer should ensure the election runs for at least 4 days, preferably in early December, after announcing it on the tei-council mailing list (and distributing ballots depending on the system).
# The results will be announced publicly on the tei-council mailing list, and Council members given a brief chance to raise any objections with the election before the current Chair informs the Board and announces it more publicly on TEI-L.
# The new Chair assumes the role on 1 January. The current chair steps down on 31 December. The outgoing and incoming chairs should co-ordinate activities between the election and 1 January so as to ensure a smooth transition. (Remembering that the current Chair might be departing off council at the end of that year.) These dates and timescales can of course shift and are not meant to be set in stone.

== Terminology ==

=== What is a "corrigible error"? ===

This is a term that comes up in Council discussions and refers to an error or inconsistency in the Guidelines that can be fixed without requiring a deprecation period.

=== What was the War on Free-text-bearing Attribute Values? ===

The War on Free-text-bearing Attribute Values, also known as the War on Free-text-bearing Attributes and the War on Attributes for short, happened because some have felt that if attribute values don't have a datatype, they are more prone to abuse than if they did. So there has been an effort to give datatypes to as many attributes as possible. Some discussion of this with respect to @rend is available here: http://blogs.oucs.ox.ac.uk/jamesc/2011/12/01/rend-and-the-war-on-text-bearing-attributes/

=== What is the "Birnbaum doctrine"? ===

As expressed in [http://www.tei-c.org/Activities/Council/Working/tcw09.xml TCW09: Backward Compatibility and the Maintenance of the Text Encoding Initiative Guidelines], we should avoid breaking backward compatibility and only do so after serious consideration. It does not mean that we cannot break backwards compatibility, just that we've agreed a set of steps to take when we do so. Our deprecation policy supersedes some of this.

=== In what ways will Council break backwards compatibility? ===

For an egregious error, we might actually change a content model immediately. More often, we will survey the community on TEI-L before doing so, and we might [[Practices no longer recommended or now deprecated|deprecate]].

=== What is the "Durand Conundrum"? ===

The "Durand Conundrum" was suggested by David G. Durand concerning the TEI's decision to use the [[ODD | TEI ODD]] meta-schema language rather than just one of the existing schema languages. Given that we decided to use our own language, why use RelaxNG as part of that language for describing content models? Generally, the consensus is that [[ODD | TEI ODD]] gives us greater power and flexibility than any individual schema language can do in that we can model things that those schema languages are currently unable to cope with. TEI ODD gives the ability for a single document to produce both documentation and schema since these are inherently interlinked. It also keeps the TEI honest, in requiring it to use its own system to document schemas. [[ODD | TEI ODD]] does currently have some problems, a few of which are detailed at [[ODD-dev]] and successive revisions of TEI ODD are intended to solve some of these. Increasingly [[ODD#Future_plans:_.22Pure_ODD.22|the work on Pure ODD elements for content models and datatypes]] has cut the gordian knot of this problem.

=== What does "no magic" mean? ===

'Magic' in the sense sometimes used in Council discussion refers to pre-existing or special knowledge required to process something. For example, it was only by 'magic' that a TEI ODD processor would know to add attributes from the att.global attribute class to elements until this was changed to make all element specifications have to explicitly claim membership in this class if they wanted the global attributes. Knowing to add them was 'magic', and in general it is better if any requirements or understood knowledge is explicitly documented. While some 'magic' of understood conventions or processing will always remain in complex technical systems, the Council strives to at very least enable the possibility of documenting the underlying rules when it discovers them. James Cummings has been a fervent proponent of the removal of any understood 'magic' rules from the TEI.

=== What is a non-deterministic content model? ===

If you have a content model for <a>:

<pre>
b*, c?, b*
</pre>

and you have a document with:

<pre>
<a>

</a>
</pre>

then a parser can't tell whether the matches the first b* or the second b* in the content model. Thus, the content model itself is called “non-deterministic”. DTDs and W3C XML Schemas reject non-deterministic content models. Thus, if we were to create one in the TEI, validation with DTD and XSD would fail due to errors ''in the schema'', regardless of whether the instance document has an occurence that is non-deterministic or not.

=== What are Janus elements? ===

These are pairs of elements that are in a sense two sides of the same coin, such as orig and reg, corr and sic, abbr and expan.

=== What does it mean to say that elements tessellate? ===

This means that all textual content is included in exactly one instance of an element. For example, once you start using divs (numbered or unnumbered), all text thereafter must be inside of one of the divs: you can't start using p elements that are not wrapped in a div.

In the Guidelines this is sometimes referred to as end-to-end segmentation.

== Meetings ==

=== Where are the minutes of previous meetings? ===

Minutes are [http://www.tei-c.org/Activities/Council/Meetings/index.xml archived on the TEI website]. Interim states of minutes may at times live in this wiki, Google Docs, or elsewhere.

=== How are the Council meetings held? ===

The Council usually makes use of Google Meet/Hangouts for their meetings. The meeting link will be in the agenda and/or sent out on the Council list before the meeting.

=== What funding is available for Council Activities? And how do I get reimbursed? ===

The TEI funds the participation of the council members in the meetings.

If the council has a meeting, then the council members' travel, hotel, etc. will be reimbursed with proper receipts. The TEI reimburses all reasonable expenses in keeping with standard practice at most universities and granting agencies. We cover meals, travel, lodging, and other common daily travel expenses. Airfare should be economy class and direct return, unless otherwise arranged with the Treasurer prior to your trip. If you have questions about reimbursement procedures, including what is reimbursable, please email Hugh Cayless, the TEI treasurer, at philomousos AT gmail.com.

Use the TEI Travel expense form available here: https://www.tei-c.org/wp-content/uploads/2017/10/TEI_travel_form.pdf '''Expense forms should be submitted within 1 month of the end of the meeting.'''

== How we get work done ==

=== I have something to say about a GitHub Feature Request or Bug: Should I comment on the issue or the TEI Council mailing list? ===

There is no hard-and-fast policy on this. The mailing list is a better place for ongoing discussions where people are arguing back and forth during decision making. The GitHub tracker is the appropriate place to record opinions, positions, and decisions for posterity, especially if such would help a) whoever is implementing the decisions recorded in the ticket, b) anyone revisiting this decision later to retrace the thinking. The [http://lists.tei-c.org/pipermail/tei-council/ TEI Council mailing list archives] are public, so if substantial discussion has taken place there (or indeed on TEI-L), this can also be linked to from the ticket.

=== When is discussion on an element or topic "closed" and how do I know? ===

Any topic can be revisited at any point, even in the published guidelines, through posting a feature request on GitHub. Council-specific issues should be raised on the council mailing list, after having reviewed any previous discussion on the topic in the [http://lists.tei-c.org/pipermail/tei-council/ tei-council mailing list archives].

=== How can I find out about every time a ticket is created or commented on? ===

Each repository has a "watch" control, which is to be found on the top right or the repo's GitHub page, below the navigation bar. This control lets you manage notifications in various ways.

=== How are tickets assigned in GitHub? ===
All members of Council are made part of the Council Team on the GitHub TEIC Organisation and meant to take an active role in the development and maintenance of the TEI Guidelines. This means that they have write access to the TEI Guidelines Github Repository, and tickets can be assigned to them in the ticket trackers. They can also update and modify tickets. This means that Council members are free to 'take' tickets which they wish to oversee. Other Council members can also 'give' tickets to each other if they think someone particularly suited to overseeing a particular ticket. (However, usually they should have the Council member's permission to do so.) On a regular basis the Council Chair will assign tickets to Council members, if a ticket gets assigned to them that they don't want to do they should tell the Chair and/or ask other Council members to swap.

=== What do the issue labels mean? ===

* 'Status: Blocked' means that the issue cannot be progressed because it requires either that another issue be completed first or that more information is needed from the reporter or a third party.

* 'Status: Needs Discussion' means that the issue has not been talked about enough yet to resolve it. New issues nearly always go into this status first. When Council has face-to-face meetings, these are usually the issues we target first.

* 'Status: Go' means that the ticket has been discussed, there is general consensus on what the correct thing to do is, and it has been assigned for someone to ensure its implementation.

* Other labels should be self-explanatory, and are sometimes created as needed to group tickets for various purposes.

=== How does a TEI release happen? ===

The process of making a release is documented at http://www.tei-c.org/Activities/Council/Working/tcw22.xml

== Working in GitHub ==

=== How do I edit the TEI Guidelines? ===

Editing the TEI Guidelines is a complex process and the Council has produced a document http://www.tei-c.org/Activities/Council/Working/tcw20.xml covering the logical and physical layout of the Guidelines, stylistic notes, how to make a change to the Guidelines (it requires [[TEI-Council-FAQ#How_do_I_use_GitHub.3F|using subversion]], building a release, and a reference section of useful information. If any information you need isn't in this document, ask on the Council list and get someone to update it!

=== How can I find out about every time a change is made in the TEI GitHub repository? ===
# Go to https://github.com/TEIC/
# Make sure you are logged in and
# go into each repository you are interested in and 'watch' them.

=== How do I use GitHub? ===
The TEI stores its working files in repositories in the [https://github.com/TEIC TEIC GitHub Organization]. See the [http://www.tei-c.org/guidelines/p5/using-the-tei-github-repository/ instructions]. Write access is reserved for those who are on the TEI Council or TEI Contributors teams. Any Council member should be able to add you to the Council team.

=== What should I put in a GitHub commit message? ===

It is beneficial to all those looking at the TEI GitHub repository if commit messages are clear and detailed. This is especially true when trying to revert changes made by yourself or others to solve problems. A good commit message will include:
* a subject line less than 72 characters long (which may be the whole message if no more is needed)
* an explanation to a useful level of detail about what you did
* a mention of why this is being done
* the GitHub issue numbers (or urls) that relate to the change if applicable
* an explanation of whether this change is completing the work described or one step towards doing so.

== TEI website ==

=== I want to add a document to add meeting minutes, reports, or working papers to the TEI-C website. How do I do that? ===

The TEI has a longstanding naming convention for files that consists of:

# a short alphabetical abbreviation for a committee (such as "tc" for "Technical Council")
# a one-letter abbreviation for minutes ("m"), reports ("r"), or working papers ("w")
# a two-digit number for the document with a committee series, numbered sequentially (e.g., "tcw01" is the first working paper from the Technical Council, "tcm05" is the fifth minutes from the Technical Council, etc.)

These documents currently reside in the [https://github.com/TEIC/Documentation Documentation] repo on GitHub.

=== How do I get access to the Google Analytics Data for www.tei-c.org? ===

Email the TEI-C webmaster: web@tei-c.org.

== Miscellaneous ==

=== Why do some elements have @type and others do not? ===

The TEI has avoided adding @type globally to elements because its availability is thought to invite tag or attribute abuse. In order for a request to add @type to an element to be considered for prolonged discussion and argument the TEI Technical Council has a standing principle that an element should be both repeatable and have obvious different classifications that apply to it. If such a request is approved then the preferred method is to make the element a member of the att.typed class (because if you can have @type, you can also have sub-types and thus need @subtype). If a closed or suggested value list, or different description is needed, this should then be provided as a local modification to the attributes inherited from att.typed.

== I have a question! ==

Then add it just above this one or email someone on the council or the council list reminding them of the existence of this wiki page when you ask your question.

[[Category:Council]]

TEI-Council-FAQ

2019-10-08T15:30:02Z

Hcayless: /* What funding is available for Council Activities? And how do I get reimbursed? */

So you have some questions about how the [[Council|TEI Technical Council]] works? This page has been set up to answer questions that new council members (or other curious parties) may have.

== Overview ==

=== How does the Council do its work? ===

By every means possible. These include monthly remote meetings, email, widely circulated discussion documents, and public debate in other contexts such as TEI-L and GitHub issues. The Council meets face to face twice a year (usually one of those meetings concurrent with the TEI Annual Meeting), and many more times than that virtually. Sub-groups of Council will often form around particularly large or complex issues and may meet separately to deal with them.

=== And what work does it do? ===

You should probably review the recent official work of the Council by reading the last few sets of minutes: http://www.tei-c.org/Council/ has an index page which links to them all (when we remember to update it). The minutes record topics discussed and responsibilities allocated at the Council level. Of course many Council members are also active in subgroups (formal or informal) of the Council or SIGs, which may be documented elsewhere as well.

Generally, things in Council work like this:

# A bug report or feature request is reported by anyone at [https://github.com/TEIC/ GitHub] for the [https://github.com/TEIC/TEI/issues Guidelines] or [https://github.com/TEIC/Stylesheets/issues Stylesheets].
# Sometimes others notice the ticket and comment on it.
# Sometimes a Council member may make an executive decision on the ticket. If it's a corrigible error or bug, we can just fix it in the appropriate ODD file(s) (also in GitHub). If it is not a real issue, sometimes the ticket will just be closed. If you do not have developer access on GitHub you'll to ask to be added to the Council team there. Otherwise, it's discussed either by email on the Council mailing list or at a Council meeting (conference call or in-person meeting). Comments are recorded in the ticket reflecting the decision reached, and changes are made in GitHub by a member of the Council sometime thereafter.
# The change shows up on tei-c.org after the next TEI "release", which happens about two or three times a year.

However, Council does sometimes consider lengthy proposals circulated to Council outside of GitHub and vote on them as packages, with the changes grouped together in a sensible way so they can be considered in smaller packages, or with the changes listed individually.

=== And what is its scope? ===

The Council's primary responsibility is to act as technical watchdog for the intellectual content of the TEI Guidelines. That is to say: it has the final say in just about every aspect of the TEI encoding scheme -- what elements exist in it, what they are called, how they should be used.

=== How do I join the TEI Council mailing list? ===

We have had the practice on the Council so far that elected members get added immediately to the list (and to the telecon, if there is one), with every right to participate, while outgoing members stay on until the end of their term. To join or discuss any problems using the list contact the [mailto:tei-council-owner@lists.tei-c.org TEI Council mailing list owner], currently this is Luis Meneses (Victoria). There is also a joint Board/Council mailing list to which you should be added as well.

=== Why are some people on the Council email list or attending Council meetings even though they are not on the list of elected members? ===

In addition to the members of the Council, the chair of the TEI Technical Council may invite others not elected to the Council to meetings (e.g. to speak to a particular issue). Historically the Council often invited a representative of the Board to the Council mailing list and meetings. The TEI-C Webmaster (currently Luis Meneses) are also on the mailing lists.

=== What are the various job roles on the TEI Council? ===

==== TEI Technical Council Member ====
A TEI Technical Council Member is expected to participate in all aspects of Council work. This means that they should learn how the TEI infrastructure is organised and [http://www.tei-c.org/Activities/Council/Working/tcw20.xml how to edit the TEI Guidelines], asking on the Council list any questions they might have. They will be expected to come to face-to-face ("f2f") meetings (often two per year) and participate in a couple other teleconferences per year. They will be assigned (or take) feature requests/bugs on [https://github.com/TEIC the TEI Consortium's GitHub site], for which they will be in charge of encouraging discussion, reporting on the issue to Council, and eventually implementing (or ensuring implementation) of the resulting decision. A TEI Technical Council Member is expected to participate in the maintenance and development of the TEI Guidelines and related outputs. Some elected TEI Council members focus more on particular aspects of the infrastructure or stylesheets as part of the contribution to the Council. Council members should always act to represent what they believe are the opinions and best interest of the community that has elected them.

==== TEI Technical Council Chair ====
The TEI Technical Council Chair's role is to administrate and facilitate the work of the TEI Technical Council. If all of the Council are the elected servants of the community, then the Council Chair is the servant of the servants of the TEI (''Servus servorum TEI''). The duties of the Technical Council Chair include (in no particular order):
* ensuring the delivery and maintenance of the Guidelines
* arranging for Council members to actively participate in Council activities
* arranging and chairing the face-to-face meetings (in conjunction with the local organiser)
* arranging and chairing the teleconferences
* creating agendas for those meetings, and ensuring minutes are written and posted of them
* assigning tickets in [http://github.com/TEIC/ the TEIC Github organization]
* acting as SIG coordinator
* liaising for and reporting on Council activities at all Board meetings
* reflecting Council wishes in Board discussions
* acting as a public point of contact and responding to technical enquiries (messages to council@tei-c.org are forwarded to the Council Chair)
* announcing new releases of the Guidelines on the TEI-L mailing list
* ensuring the smooth running of the TEI Technical Council

The TEI Technical Council Chair is also a member of the Council, so has all the duties and obligations of being a council member as well.

==== Release Technician ====
The TEI Guidelines release process (see [http://www.tei-c.org/Activities/Council/Working/tcw22.xml tcw22: Building a TEI Release]) involves a single individual responsible for 'pushing the button' and completing the steps required to make a TEI Guidelines release live. This is not a standing position; instead, the responsibility rotates for every release in order to demystify the release process and spread the expertise beyond Oxford staff. Although we have documented the work in quite a detailed manner, it is a non-trivial process and involves a fair degree of work. A release technician is usually required to set aside a whole day for the release process since history teaches us that often the entire process needs to be re-run to correct last-minute errors.

==== TEI-C Webmaster and Assistant Webmaster ====

The TEI-C Webmaster and Assistant Webmaster are not officially part of the Council but may be added to the mailing lists at the discretion of the Council Chair. They are responsible for the smooth running of the TEI-C Website.

=== How is the TEI Technical Council Chair elected? ===

The [http://www.tei-c.org/About/bylaws.xml#body.1_div.3_div.3 Bylaws of the TEI-C] say that:
<blockquote>
The Chair of the Technical Council shall be elected by the voting Members of the TEI-C Technical Council from its membership and shall serve as the chief technical officer of the Consortium. If no Technical Council Member is able or willing to assume the chair, the Technical Council may request the Board of Directors to second one of its elected members to the role, or it may nominate a non-elected individual.
</blockquote>
This leaves it intentionally vague as to the precise process the TEI Technical Council will follow. For now there is vague consensus that they will do something like the following. Note that timeframes below are not intended to be rigid or precise, but rather to be suggestive.
# The new Technical Council Members will be added to the tei-council (and tei-board-council) mailing lists shortly after the members' meeting. Up until around the last last Friday in November those who are Council members for next year will consider whether they want to run to be Chair of the TEI Technical Council. The current Chair will facilitate this process by answering any questions about the post. Before that date those intending to stand should send a statement of some sort to the Council mailing list detailing why they think the council members should vote for them.
# On or around the first weekday of December if only one person is running then the Chair will announce this to the tei-council mailing list as an acclamation (and after a short period for objections, to the Board and TEI-L). If multiple people are running, then the Council Chair will appoint a "returning officer" who is not a member of the incoming Council (i.e., not a voter and thus at least a somewhat disinterested party). The returning officer will set up an electronic voting system with the names of the candidates. This should be a private election with no one able to determine who has voted for whom. E.g. if using opavote.org this should have the following settings:
## Results only shown at end
## Method: "Plurality/FPTP/SNTV" for 2 candidates, "Instant Runoff Voting" for 3 or more
## a single winner
## Ballot type: "choose one" for 2 candidates, "ranked enhanced" for 3 or more
## candidate order shuffled
# The returning officer should ensure the election runs for at least 4 days, preferably in early December, after announcing it on the tei-council mailing list (and distributing ballots depending on the system).
# The results will be announced publicly on the tei-council mailing list, and Council members given a brief chance to raise any objections with the election before the current Chair informs the Board and announces it more publicly on TEI-L.
# The new Chair assumes the role on 1 January. The current chair steps down on 31 December. The outgoing and incoming chairs should co-ordinate activities between the election and 1 January so as to ensure a smooth transition. (Remembering that the current Chair might be departing off council at the end of that year.) These dates and timescales can of course shift and are not meant to be set in stone.

== Terminology ==

=== What was the War on Free-text-bearing Attribute Values? ===

The War on Free-text-bearing Attribute Values, also known as the War on Free-text-bearing Attributes and the War on Attributes for short, happened because some have felt that if attribute values don't have a datatype, they are more prone to abuse than if they did. So there has been an effort to give datatypes to as many attributes as possible. Some discussion of this with respect to @rend is available here: http://blogs.oucs.ox.ac.uk/jamesc/2011/12/01/rend-and-the-war-on-text-bearing-attributes/

=== What is the "Birnbaum doctrine"? ===

As expressed in [http://www.tei-c.org/Activities/Council/Working/tcw09.xml TCW09: Backward Compatibility and the Maintenance of the Text Encoding Initiative Guidelines], we should avoid breaking backward compatibility and only do so after serious consideration. It does not mean that we cannot break backwards compatibility, just that we've agreed a set of steps to take when we do so. Our deprecation policy supersedes some of this.

=== In what ways will Council break backwards compatibility? ===

For an egregious error, we might actually change a content model immediately. More often, we will survey the community on TEI-L before doing so, and we might [[Practices no longer recommended or now deprecated|deprecate]].

=== What is the "Durand Conundrum"? ===

The "Durand Conundrum" was suggested by David G. Durand concerning the TEI's decision to use the [[ODD | TEI ODD]] meta-schema language rather than just one of the existing schema languages. Given that we decided to use our own language, why use RelaxNG as part of that language for describing content models? Generally, the consensus is that [[ODD | TEI ODD]] gives us greater power and flexibility than any individual schema language can do in that we can model things that those schema languages are currently unable to cope with. TEI ODD gives the ability for a single document to produce both documentation and schema since these are inherently interlinked. It also keeps the TEI honest, in requiring it to use its own system to document schemas. [[ODD | TEI ODD]] does currently have some problems, a few of which are detailed at [[ODD-dev]] and successive revisions of TEI ODD are intended to solve some of these. Increasingly [[ODD#Future_plans:_.22Pure_ODD.22|the work on Pure ODD elements for content models and datatypes]] has cut the gordian knot of this problem.

=== What does "no magic" mean? ===

'Magic' in the sense sometimes used in Council discussion refers to pre-existing or special knowledge required to process something. For example, it was only by 'magic' that a TEI ODD processor would know to add attributes from the att.global attribute class to elements until this was changed to make all element specifications have to explicitly claim membership in this class if they wanted the global attributes. Knowing to add them was 'magic', and in general it is better if any requirements or understood knowledge is explicitly documented. While some 'magic' of understood conventions or processing will always remain in complex technical systems, the Council strives to at very least enable the possibility of documenting the underlying rules when it discovers them. James Cummings has been a fervent proponent of the removal of any understood 'magic' rules from the TEI.

=== What is a "magic token"? ===

This is an value, usually an attribute value, such as that of @key or @rend, which does not follow a standard outside vocabulary but instead is understood in some undocumented way and often used for local processing. It should usually be explained in the teiHeader if possible. Having any processing rely on undocumented magic tokens is generally considered a bad idea. See also [http://en.wikipedia.org/wiki/Magic_cookie Magic Cookie].

=== What is a non-deterministic content model? ===

If you have a content model for <a>:

<pre>
b*, c?, b*
</pre>

and you have a document with:

<pre>
<a>

</a>
</pre>

then a parser can't tell whether the matches the first b* or the second b* in the content model. Thus, the content model itself is called “non-deterministic”. DTDs and W3C XML Schemas reject non-deterministic content models. Thus, if we were to create one in the TEI, validation with DTD and XSD would fail due to errors ''in the schema'', regardless of whether the instance document has an occurence that is non-deterministic or not.

=== What are Janus elements? ===

These are pairs of elements that are in a sense two sides of the same coin, such as orig and reg, corr and sic, abbr and expan.

=== What does it mean to say that elements tessellate? ===

This means that all textual content is included in exactly one instance of an element. For example, once you start using divs (numbered or unnumbered), all text thereafter must be inside of one of the divs: you can't start using p elements that are not wrapped in a div.

In the Guidelines this is sometimes referred to as end-to-end segmentation.

== Meetings ==

=== Where are the minutes of previous meetings? ===

Minutes are [http://www.tei-c.org/Activities/Council/Meetings/index.xml archived on the TEI website]. Interim states of minutes may at times live in this wiki, Google Docs, or elsewhere.

=== How are the Council meetings held? ===

The Council usually makes use of Google Meet/Hangouts for their meetings. The meeting link will be in the agenda and/or sent out on the Council list before the meeting.

=== What funding is available for Council Activities? And how do I get reimbursed? ===

The TEI funds the participation of the council members in the meetings.

If the council has a meeting, then the council members' travel, hotel, etc. will be reimbursed with proper receipts. The TEI reimburses all reasonable expenses in keeping with standard practice at most universities and granting agencies. We cover meals, travel, lodging, and other common daily travel expenses. Airfare should be economy class and direct return, unless otherwise arranged with the Treasurer prior to your trip. If you have questions about reimbursement procedures, including what is reimbursable, please email Hugh Cayless, the TEI treasurer, at philomousos AT gmail.com.

Use the TEI Travel expense form available here: https://www.tei-c.org/wp-content/uploads/2017/10/TEI_travel_form.pdf '''Expense forms should be submitted within 1 month of the end of the meeting.'''

== How we get work done ==

=== I have something to say about a GitHub Feature Request or Bug: Should I comment on the issue or the TEI Council mailing list? ===

There is no hard-and-fast policy on this. The mailing list is a better place for ongoing discussions where people are arguing back and forth during decision making. The GitHub tracker is the appropriate place to record opinions, positions, and decisions for posterity, especially if such would help a) whoever is implementing the decisions recorded in the ticket, b) anyone revisiting this decision later to retrace the thinking. The [http://lists.tei-c.org/pipermail/tei-council/ TEI Council mailing list archives] are public, so if substantial discussion has taken place there (or indeed on TEI-L), this can also be linked to from the ticket.

=== When is discussion on an element or topic "closed" and how do I know? ===

Any topic can be revisited at any point, even in the published guidelines, through posting a feature request on GitHub. Council-specific issues should be raised on the council mailing list, after having reviewed any previous discussion on the topic in the [http://lists.tei-c.org/pipermail/tei-council/ tei-council mailing list archives].

=== How can I find out about every time a ticket is created or commented on? ===

Each repository has a "watch" control, which is to be found on the top right or the repo's GitHub page, below the navigation bar. This control lets you manage notifications in various ways.

=== How are tickets assigned in GitHub? ===
All members of Council are made part of the Council Team on the GitHub TEIC Organisation and meant to take an active role in the development and maintenance of the TEI Guidelines. This means that they have write access to the TEI Guidelines Github Repository, and tickets can be assigned to them in the ticket trackers. They can also update and modify tickets. This means that Council members are free to 'take' tickets which they wish to oversee. Other Council members can also 'give' tickets to each other if they think someone particularly suited to overseeing a particular ticket. (However, usually they should have the Council member's permission to do so.) On a regular basis the Council Chair will assign tickets to Council members, if a ticket gets assigned to them that they don't want to do they should tell the Chair and/or ask other Council members to swap.

=== What do the issue labels mean? ===

* 'Status: Blocked' means that the issue cannot be progressed because it requires either that another issue be completed first or that more information is needed from the reporter or a third party.

* 'Status: Needs Discussion' means that the issue has not been talked about enough yet to resolve it. New issues nearly always go into this status first. When Council has face-to-face meetings, these are usually the issues we target first.

* 'Status: Go' means that the ticket has been discussed, there is general consensus on what the correct thing to do is, and it has been assigned for someone to ensure its implementation.

* Other labels should be self-explanatory, and are sometimes created as needed to group tickets for various purposes.

=== How does a TEI release happen? ===

The process of making a release is documented at http://www.tei-c.org/Activities/Council/Working/tcw22.xml

== Working in GitHub ==

=== How do I edit the TEI Guidelines? ===

Editing the TEI Guidelines is a complex process and the Council has produced a document http://www.tei-c.org/Activities/Council/Working/tcw20.xml covering the logical and physical layout of the Guidelines, stylistic notes, how to make a change to the Guidelines (it requires [[TEI-Council-FAQ#How_do_I_use_GitHub.3F|using subversion]], building a release, and a reference section of useful information. If any information you need isn't in this document, ask on the Council list and get someone to update it!

=== How can I find out about every time a change is made in the TEI GitHub repository? ===
# Go to https://github.com/TEIC/
# Make sure you are logged in and
# go into each repository you are interested in and 'watch' them.

=== How do I use GitHub? ===
The TEI stores its working files in repositories in the [https://github.com/TEIC TEIC GitHub Organization]. See the [http://www.tei-c.org/guidelines/p5/using-the-tei-github-repository/ instructions]. Write access is reserved for those who are on the TEI Council or TEI Contributors teams. Any Council member should be able to add you to the Council team.

=== What should I put in a GitHub commit message? ===

It is beneficial to all those looking at the TEI GitHub repository if commit messages are clear and detailed. This is especially true when trying to revert changes made by yourself or others to solve problems. A good commit message will include:
* a subject line less than 72 characters long (which may be the whole message if no more is needed)
* an explanation to a useful level of detail about what you did
* a mention of why this is being done
* the GitHub issue numbers (or urls) that relate to the change if applicable
* an explanation of whether this change is completing the work described or one step towards doing so.

== TEI website ==

=== I want to add a document to add meeting minutes, reports, or working papers to the TEI-C website. How do I do that? ===

The TEI has a longstanding naming convention for files that consists of:

# a short alphabetical abbreviation for a committee (such as "tc" for "Technical Council")
# a one-letter abbreviation for minutes ("m"), reports ("r"), or working papers ("w")
# a two-digit number for the document with a committee series, numbered sequentially (e.g., "tcw01" is the first working paper from the Technical Council, "tcm05" is the fifth minutes from the Technical Council, etc.)

These documents currently reside in the [https://github.com/TEIC/Documentation Documentation] repo on GitHub.

=== How do I get access to the Google Analytics Data for www.tei-c.org? ===

Email the TEI-C webmaster: web@tei-c.org.

== Miscellaneous ==

=== Why do some elements have @type and others do not? ===

The TEI has avoided adding @type globally to elements because its availability is thought to invite tag or attribute abuse. In order for a request to add @type to an element to be considered for prolonged discussion and argument the TEI Technical Council has a standing principle that an element should be both repeatable and have obvious different classifications that apply to it. If such a request is approved then the preferred method is to make the element a member of the att.typed class (because if you can have @type, you can also have sub-types and thus need @subtype). If a closed or suggested value list, or different description is needed, this should then be provided as a local modification to the attributes inherited from att.typed.

== I have a question! ==

Then add it just above this one or email someone on the council or the council list reminding them of the existence of this wiki page when you ask your question.

[[Category:Council]]

TEI-Council-FAQ

2019-10-08T14:56:28Z

Hcayless: /* I want to add a document to add meeting minutes, reports, or working papers to the TEI-C website. How do I do that? */

So you have some questions about how the [[Council|TEI Technical Council]] works? This page has been set up to answer questions that new council members (or other curious parties) may have.

== Overview ==

=== How does the Council do its work? ===

By every means possible. These include monthly remote meetings, email, widely circulated discussion documents, and public debate in other contexts such as TEI-L and GitHub issues. The Council meets face to face twice a year (usually one of those meetings concurrent with the TEI Annual Meeting), and many more times than that virtually. Sub-groups of Council will often form around particularly large or complex issues and may meet separately to deal with them.

=== And what work does it do? ===

You should probably review the recent official work of the Council by reading the last few sets of minutes: http://www.tei-c.org/Council/ has an index page which links to them all (when we remember to update it). The minutes record topics discussed and responsibilities allocated at the Council level. Of course many Council members are also active in subgroups (formal or informal) of the Council or SIGs, which may be documented elsewhere as well.

Generally, things in Council work like this:

# A bug report or feature request is reported by anyone at [https://github.com/TEIC/ GitHub] for the [https://github.com/TEIC/TEI/issues Guidelines] or [https://github.com/TEIC/Stylesheets/issues Stylesheets].
# Sometimes others notice the ticket and comment on it.
# Sometimes a Council member may make an executive decision on the ticket. If it's a corrigible error or bug, we can just fix it in the appropriate ODD file(s) (also in GitHub). If it is not a real issue, sometimes the ticket will just be closed. If you do not have developer access on GitHub you'll to ask to be added to the Council team there. Otherwise, it's discussed either by email on the Council mailing list or at a Council meeting (conference call or in-person meeting). Comments are recorded in the ticket reflecting the decision reached, and changes are made in GitHub by a member of the Council sometime thereafter.
# The change shows up on tei-c.org after the next TEI "release", which happens about two or three times a year.

However, Council does sometimes consider lengthy proposals circulated to Council outside of GitHub and vote on them as packages, with the changes grouped together in a sensible way so they can be considered in smaller packages, or with the changes listed individually.

=== And what is its scope? ===

The Council's primary responsibility is to act as technical watchdog for the intellectual content of the TEI Guidelines. That is to say: it has the final say in just about every aspect of the TEI encoding scheme -- what elements exist in it, what they are called, how they should be used.

=== How do I join the TEI Council mailing list? ===

We have had the practice on the Council so far that elected members get added immediately to the list (and to the telecon, if there is one), with every right to participate, while outgoing members stay on until the end of their term. To join or discuss any problems using the list contact the [mailto:tei-council-owner@lists.tei-c.org TEI Council mailing list owner], currently this is Luis Meneses (Victoria). There is also a joint Board/Council mailing list to which you should be added as well.

=== Why are some people on the Council email list or attending Council meetings even though they are not on the list of elected members? ===

In addition to the members of the Council, the chair of the TEI Technical Council may invite others not elected to the Council to meetings (e.g. to speak to a particular issue). Historically the Council often invited a representative of the Board to the Council mailing list and meetings. The TEI-C Webmaster (currently Luis Meneses) are also on the mailing lists.

=== What are the various job roles on the TEI Council? ===

==== TEI Technical Council Member ====
A TEI Technical Council Member is expected to participate in all aspects of Council work. This means that they should learn how the TEI infrastructure is organised and [http://www.tei-c.org/Activities/Council/Working/tcw20.xml how to edit the TEI Guidelines], asking on the Council list any questions they might have. They will be expected to come to face-to-face ("f2f") meetings (often two per year) and participate in a couple other teleconferences per year. They will be assigned (or take) feature requests/bugs on [https://github.com/TEIC the TEI Consortium's GitHub site], for which they will be in charge of encouraging discussion, reporting on the issue to Council, and eventually implementing (or ensuring implementation) of the resulting decision. A TEI Technical Council Member is expected to participate in the maintenance and development of the TEI Guidelines and related outputs. Some elected TEI Council members focus more on particular aspects of the infrastructure or stylesheets as part of the contribution to the Council. Council members should always act to represent what they believe are the opinions and best interest of the community that has elected them.

==== TEI Technical Council Chair ====
The TEI Technical Council Chair's role is to administrate and facilitate the work of the TEI Technical Council. If all of the Council are the elected servants of the community, then the Council Chair is the servant of the servants of the TEI (''Servus servorum TEI''). The duties of the Technical Council Chair include (in no particular order):
* ensuring the delivery and maintenance of the Guidelines
* arranging for Council members to actively participate in Council activities
* arranging and chairing the face-to-face meetings (in conjunction with the local organiser)
* arranging and chairing the teleconferences
* creating agendas for those meetings, and ensuring minutes are written and posted of them
* assigning tickets in [http://github.com/TEIC/ the TEIC Github organization]
* acting as SIG coordinator
* liaising for and reporting on Council activities at all Board meetings
* reflecting Council wishes in Board discussions
* acting as a public point of contact and responding to technical enquiries (messages to council@tei-c.org are forwarded to the Council Chair)
* announcing new releases of the Guidelines on the TEI-L mailing list
* ensuring the smooth running of the TEI Technical Council

The TEI Technical Council Chair is also a member of the Council, so has all the duties and obligations of being a council member as well.

==== Release Technician ====
The TEI Guidelines release process (see [http://www.tei-c.org/Activities/Council/Working/tcw22.xml tcw22: Building a TEI Release]) involves a single individual responsible for 'pushing the button' and completing the steps required to make a TEI Guidelines release live. This is not a standing position; instead, the responsibility rotates for every release in order to demystify the release process and spread the expertise beyond Oxford staff. Although we have documented the work in quite a detailed manner, it is a non-trivial process and involves a fair degree of work. A release technician is usually required to set aside a whole day for the release process since history teaches us that often the entire process needs to be re-run to correct last-minute errors.

==== TEI-C Webmaster and Assistant Webmaster ====

The TEI-C Webmaster and Assistant Webmaster are not officially part of the Council but may be added to the mailing lists at the discretion of the Council Chair. They are responsible for the smooth running of the TEI-C Website.

=== How is the TEI Technical Council Chair elected? ===

The [http://www.tei-c.org/About/bylaws.xml#body.1_div.3_div.3 Bylaws of the TEI-C] say that:
<blockquote>
The Chair of the Technical Council shall be elected by the voting Members of the TEI-C Technical Council from its membership and shall serve as the chief technical officer of the Consortium. If no Technical Council Member is able or willing to assume the chair, the Technical Council may request the Board of Directors to second one of its elected members to the role, or it may nominate a non-elected individual.
</blockquote>
This leaves it intentionally vague as to the precise process the TEI Technical Council will follow. For now there is vague consensus that they will do something like the following. Note that timeframes below are not intended to be rigid or precise, but rather to be suggestive.
# The new Technical Council Members will be added to the tei-council (and tei-board-council) mailing lists shortly after the members' meeting. Up until around the last last Friday in November those who are Council members for next year will consider whether they want to run to be Chair of the TEI Technical Council. The current Chair will facilitate this process by answering any questions about the post. Before that date those intending to stand should send a statement of some sort to the Council mailing list detailing why they think the council members should vote for them.
# On or around the first weekday of December if only one person is running then the Chair will announce this to the tei-council mailing list as an acclamation (and after a short period for objections, to the Board and TEI-L). If multiple people are running, then the Council Chair will appoint a "returning officer" who is not a member of the incoming Council (i.e., not a voter and thus at least a somewhat disinterested party). The returning officer will set up an electronic voting system with the names of the candidates. This should be a private election with no one able to determine who has voted for whom. E.g. if using opavote.org this should have the following settings:
## Results only shown at end
## Method: "Plurality/FPTP/SNTV" for 2 candidates, "Instant Runoff Voting" for 3 or more
## a single winner
## Ballot type: "choose one" for 2 candidates, "ranked enhanced" for 3 or more
## candidate order shuffled
# The returning officer should ensure the election runs for at least 4 days, preferably in early December, after announcing it on the tei-council mailing list (and distributing ballots depending on the system).
# The results will be announced publicly on the tei-council mailing list, and Council members given a brief chance to raise any objections with the election before the current Chair informs the Board and announces it more publicly on TEI-L.
# The new Chair assumes the role on 1 January. The current chair steps down on 31 December. The outgoing and incoming chairs should co-ordinate activities between the election and 1 January so as to ensure a smooth transition. (Remembering that the current Chair might be departing off council at the end of that year.) These dates and timescales can of course shift and are not meant to be set in stone.

== Terminology ==

=== What was the War on Free-text-bearing Attribute Values? ===

The War on Free-text-bearing Attribute Values, also known as the War on Free-text-bearing Attributes and the War on Attributes for short, happened because some have felt that if attribute values don't have a datatype, they are more prone to abuse than if they did. So there has been an effort to give datatypes to as many attributes as possible. Some discussion of this with respect to @rend is available here: http://blogs.oucs.ox.ac.uk/jamesc/2011/12/01/rend-and-the-war-on-text-bearing-attributes/

=== What is the "Birnbaum doctrine"? ===

As expressed in [http://www.tei-c.org/Activities/Council/Working/tcw09.xml TCW09: Backward Compatibility and the Maintenance of the Text Encoding Initiative Guidelines], we should avoid breaking backward compatibility and only do so after serious consideration. It does not mean that we cannot break backwards compatibility, just that we've agreed a set of steps to take when we do so. Our deprecation policy supersedes some of this.

=== In what ways will Council break backwards compatibility? ===

For an egregious error, we might actually change a content model immediately. More often, we will survey the community on TEI-L before doing so, and we might [[Practices no longer recommended or now deprecated|deprecate]].

=== What is the "Durand Conundrum"? ===

The "Durand Conundrum" was suggested by David G. Durand concerning the TEI's decision to use the [[ODD | TEI ODD]] meta-schema language rather than just one of the existing schema languages. Given that we decided to use our own language, why use RelaxNG as part of that language for describing content models? Generally, the consensus is that [[ODD | TEI ODD]] gives us greater power and flexibility than any individual schema language can do in that we can model things that those schema languages are currently unable to cope with. TEI ODD gives the ability for a single document to produce both documentation and schema since these are inherently interlinked. It also keeps the TEI honest, in requiring it to use its own system to document schemas. [[ODD | TEI ODD]] does currently have some problems, a few of which are detailed at [[ODD-dev]] and successive revisions of TEI ODD are intended to solve some of these. Increasingly [[ODD#Future_plans:_.22Pure_ODD.22|the work on Pure ODD elements for content models and datatypes]] has cut the gordian knot of this problem.

=== What does "no magic" mean? ===

'Magic' in the sense sometimes used in Council discussion refers to pre-existing or special knowledge required to process something. For example, it was only by 'magic' that a TEI ODD processor would know to add attributes from the att.global attribute class to elements until this was changed to make all element specifications have to explicitly claim membership in this class if they wanted the global attributes. Knowing to add them was 'magic', and in general it is better if any requirements or understood knowledge is explicitly documented. While some 'magic' of understood conventions or processing will always remain in complex technical systems, the Council strives to at very least enable the possibility of documenting the underlying rules when it discovers them. James Cummings has been a fervent proponent of the removal of any understood 'magic' rules from the TEI.

=== What is a "magic token"? ===

This is an value, usually an attribute value, such as that of @key or @rend, which does not follow a standard outside vocabulary but instead is understood in some undocumented way and often used for local processing. It should usually be explained in the teiHeader if possible. Having any processing rely on undocumented magic tokens is generally considered a bad idea. See also [http://en.wikipedia.org/wiki/Magic_cookie Magic Cookie].

=== What is a non-deterministic content model? ===

If you have a content model for <a>:

<pre>
b*, c?, b*
</pre>

and you have a document with:

<pre>
<a>

</a>
</pre>

then a parser can't tell whether the matches the first b* or the second b* in the content model. Thus, the content model itself is called “non-deterministic”. DTDs and W3C XML Schemas reject non-deterministic content models. Thus, if we were to create one in the TEI, validation with DTD and XSD would fail due to errors ''in the schema'', regardless of whether the instance document has an occurence that is non-deterministic or not.

=== What are Janus elements? ===

These are pairs of elements that are in a sense two sides of the same coin, such as orig and reg, corr and sic, abbr and expan.

=== What does it mean to say that elements tessellate? ===

This means that all textual content is included in exactly one instance of an element. For example, once you start using divs (numbered or unnumbered), all text thereafter must be inside of one of the divs: you can't start using p elements that are not wrapped in a div.

In the Guidelines this is sometimes referred to as end-to-end segmentation.

== Meetings ==

=== Where are the minutes of previous meetings? ===

Minutes are [http://www.tei-c.org/Activities/Council/Meetings/index.xml archived on the TEI website]. Interim states of minutes may at times live in this wiki, Google Docs, or elsewhere.

=== How are the Council meetings held? ===

The Council usually makes use of Google Meet/Hangouts for their meetings. The meeting link will be in the agenda and/or sent out on the Council list before the meeting.

=== What funding is available for Council Activities? And how do I get reimbursed? ===

The TEI funds the participation of the council members in the meetings. Though I don't know of anyone claiming back telephone conferencing costs, I suppose that is possible as well, in most cases the council members' institutions probably swallow that.

If the council has a meeting, then the council members' travel, hotel, etc. will be reimbursed with proper receipts. The TEI reimburses all reasonable expenses in keeping with standard practice at most universities and granting agencies. We cover meals, travel, lodging, and other common daily travel expenses. Airfare should be economy class and direct return, unless otherwise arranged with the Treasurer prior to your trip. (See [http://www.tei-c.org/Board/procedures.xml#body.1_div.8 draft reimbursement policies and procedures].) If you have questions about reimbursement procedures, including what is reimbursable, please email John Unsworth, the TEI treasurer, at john.m.unsworth AT gmail.com.

Use the TEI Travel expense form available here: https://www.tei-c.org/wp-content/uploads/2017/10/TEI_travel_form.pdf '''Expense forms should be submitted within 10 days of the end of the meeting.'''

Council members are not funded to attend the TEI Members' Meeting, however, there has been discussion concerning whether the council should also officially meet here as well.

== How we get work done ==

=== I have something to say about a GitHub Feature Request or Bug: Should I comment on the issue or the TEI Council mailing list? ===

There is no hard-and-fast policy on this. The mailing list is a better place for ongoing discussions where people are arguing back and forth during decision making. The GitHub tracker is the appropriate place to record opinions, positions, and decisions for posterity, especially if such would help a) whoever is implementing the decisions recorded in the ticket, b) anyone revisiting this decision later to retrace the thinking. The [http://lists.tei-c.org/pipermail/tei-council/ TEI Council mailing list archives] are public, so if substantial discussion has taken place there (or indeed on TEI-L), this can also be linked to from the ticket.

=== When is discussion on an element or topic "closed" and how do I know? ===

Any topic can be revisited at any point, even in the published guidelines, through posting a feature request on GitHub. Council-specific issues should be raised on the council mailing list, after having reviewed any previous discussion on the topic in the [http://lists.tei-c.org/pipermail/tei-council/ tei-council mailing list archives].

=== How can I find out about every time a ticket is created or commented on? ===

Each repository has a "watch" control, which is to be found on the top right or the repo's GitHub page, below the navigation bar. This control lets you manage notifications in various ways.

=== How are tickets assigned in GitHub? ===
All members of Council are made part of the Council Team on the GitHub TEIC Organisation and meant to take an active role in the development and maintenance of the TEI Guidelines. This means that they have write access to the TEI Guidelines Github Repository, and tickets can be assigned to them in the ticket trackers. They can also update and modify tickets. This means that Council members are free to 'take' tickets which they wish to oversee. Other Council members can also 'give' tickets to each other if they think someone particularly suited to overseeing a particular ticket. (However, usually they should have the Council member's permission to do so.) On a regular basis the Council Chair will assign tickets to Council members, if a ticket gets assigned to them that they don't want to do they should tell the Chair and/or ask other Council members to swap.

=== What do the issue labels mean? ===

* 'Status: Blocked' means that the issue cannot be progressed because it requires either that another issue be completed first or that more information is needed from the reporter or a third party.

* 'Status: Needs Discussion' means that the issue has not been talked about enough yet to resolve it. New issues nearly always go into this status first. When Council has face-to-face meetings, these are usually the issues we target first.

* 'Status: Go' means that the ticket has been discussed, there is general consensus on what the correct thing to do is, and it has been assigned for someone to ensure its implementation.

* Other labels should be self-explanatory, and are sometimes created as needed to group tickets for various purposes.

=== How does a TEI release happen? ===

The process of making a release is documented at http://www.tei-c.org/Activities/Council/Working/tcw22.xml

== Working in GitHub ==

=== How do I edit the TEI Guidelines? ===

Editing the TEI Guidelines is a complex process and the Council has produced a document http://www.tei-c.org/Activities/Council/Working/tcw20.xml covering the logical and physical layout of the Guidelines, stylistic notes, how to make a change to the Guidelines (it requires [[TEI-Council-FAQ#How_do_I_use_GitHub.3F|using subversion]], building a release, and a reference section of useful information. If any information you need isn't in this document, ask on the Council list and get someone to update it!

=== How can I find out about every time a change is made in the TEI GitHub repository? ===
# Go to https://github.com/TEIC/
# Make sure you are logged in and
# go into each repository you are interested in and 'watch' them.

=== How do I use GitHub? ===
The TEI stores its working files in repositories in the [https://github.com/TEIC TEIC GitHub Organization]. See the [http://www.tei-c.org/guidelines/p5/using-the-tei-github-repository/ instructions]. Write access is reserved for those who are on the TEI Council or TEI Contributors teams. Any Council member should be able to add you to the Council team.

=== What should I put in a GitHub commit message? ===

It is beneficial to all those looking at the TEI GitHub repository if commit messages are clear and detailed. This is especially true when trying to revert changes made by yourself or others to solve problems. A good commit message will include:
* a subject line less than 72 characters long (which may be the whole message if no more is needed)
* an explanation to a useful level of detail about what you did
* a mention of why this is being done
* the GitHub issue numbers (or urls) that relate to the change if applicable
* an explanation of whether this change is completing the work described or one step towards doing so.

== TEI website ==

=== I want to add a document to add meeting minutes, reports, or working papers to the TEI-C website. How do I do that? ===

The TEI has a longstanding naming convention for files that consists of:

# a short alphabetical abbreviation for a committee (such as "tc" for "Technical Council")
# a one-letter abbreviation for minutes ("m"), reports ("r"), or working papers ("w")
# a two-digit number for the document with a committee series, numbered sequentially (e.g., "tcw01" is the first working paper from the Technical Council, "tcm05" is the fifth minutes from the Technical Council, etc.)

These documents currently reside in the [https://github.com/TEIC/Documentation Documentation] repo on GitHub.

=== How do I get access to the Google Analytics Data for www.tei-c.org? ===

Email the TEI-C webmaster: web@tei-c.org.

== Miscellaneous ==

=== Why do some elements have @type and others do not? ===

The TEI has avoided adding @type globally to elements because its availability is thought to invite tag or attribute abuse. In order for a request to add @type to an element to be considered for prolonged discussion and argument the TEI Technical Council has a standing principle that an element should be both repeatable and have obvious different classifications that apply to it. If such a request is approved then the preferred method is to make the element a member of the att.typed class (because if you can have @type, you can also have sub-types and thus need @subtype). If a closed or suggested value list, or different description is needed, this should then be provided as a local modification to the attributes inherited from att.typed.

== I have a question! ==

Then add it just above this one or email someone on the council or the council list reminding them of the existence of this wiki page when you ask your question.

[[Category:Council]]

TEI-Council-FAQ

2019-10-08T14:53:59Z

Hcayless: /* Why are some people on the Council email list or attending Council meetings even though they are not on the list of elected members? */

So you have some questions about how the [[Council|TEI Technical Council]] works? This page has been set up to answer questions that new council members (or other curious parties) may have.

== Overview ==

=== How does the Council do its work? ===

By every means possible. These include monthly remote meetings, email, widely circulated discussion documents, and public debate in other contexts such as TEI-L and GitHub issues. The Council meets face to face twice a year (usually one of those meetings concurrent with the TEI Annual Meeting), and many more times than that virtually. Sub-groups of Council will often form around particularly large or complex issues and may meet separately to deal with them.

=== And what work does it do? ===

You should probably review the recent official work of the Council by reading the last few sets of minutes: http://www.tei-c.org/Council/ has an index page which links to them all (when we remember to update it). The minutes record topics discussed and responsibilities allocated at the Council level. Of course many Council members are also active in subgroups (formal or informal) of the Council or SIGs, which may be documented elsewhere as well.

Generally, things in Council work like this:

# A bug report or feature request is reported by anyone at [https://github.com/TEIC/ GitHub] for the [https://github.com/TEIC/TEI/issues Guidelines] or [https://github.com/TEIC/Stylesheets/issues Stylesheets].
# Sometimes others notice the ticket and comment on it.
# Sometimes a Council member may make an executive decision on the ticket. If it's a corrigible error or bug, we can just fix it in the appropriate ODD file(s) (also in GitHub). If it is not a real issue, sometimes the ticket will just be closed. If you do not have developer access on GitHub you'll to ask to be added to the Council team there. Otherwise, it's discussed either by email on the Council mailing list or at a Council meeting (conference call or in-person meeting). Comments are recorded in the ticket reflecting the decision reached, and changes are made in GitHub by a member of the Council sometime thereafter.
# The change shows up on tei-c.org after the next TEI "release", which happens about two or three times a year.

However, Council does sometimes consider lengthy proposals circulated to Council outside of GitHub and vote on them as packages, with the changes grouped together in a sensible way so they can be considered in smaller packages, or with the changes listed individually.

=== And what is its scope? ===

The Council's primary responsibility is to act as technical watchdog for the intellectual content of the TEI Guidelines. That is to say: it has the final say in just about every aspect of the TEI encoding scheme -- what elements exist in it, what they are called, how they should be used.

=== How do I join the TEI Council mailing list? ===

We have had the practice on the Council so far that elected members get added immediately to the list (and to the telecon, if there is one), with every right to participate, while outgoing members stay on until the end of their term. To join or discuss any problems using the list contact the [mailto:tei-council-owner@lists.tei-c.org TEI Council mailing list owner], currently this is Luis Meneses (Victoria). There is also a joint Board/Council mailing list to which you should be added as well.

=== Why are some people on the Council email list or attending Council meetings even though they are not on the list of elected members? ===

In addition to the members of the Council, the chair of the TEI Technical Council may invite others not elected to the Council to meetings (e.g. to speak to a particular issue). Historically the Council often invited a representative of the Board to the Council mailing list and meetings. The TEI-C Webmaster (currently Luis Meneses) are also on the mailing lists.

=== What are the various job roles on the TEI Council? ===

==== TEI Technical Council Member ====
A TEI Technical Council Member is expected to participate in all aspects of Council work. This means that they should learn how the TEI infrastructure is organised and [http://www.tei-c.org/Activities/Council/Working/tcw20.xml how to edit the TEI Guidelines], asking on the Council list any questions they might have. They will be expected to come to face-to-face ("f2f") meetings (often two per year) and participate in a couple other teleconferences per year. They will be assigned (or take) feature requests/bugs on [https://github.com/TEIC the TEI Consortium's GitHub site], for which they will be in charge of encouraging discussion, reporting on the issue to Council, and eventually implementing (or ensuring implementation) of the resulting decision. A TEI Technical Council Member is expected to participate in the maintenance and development of the TEI Guidelines and related outputs. Some elected TEI Council members focus more on particular aspects of the infrastructure or stylesheets as part of the contribution to the Council. Council members should always act to represent what they believe are the opinions and best interest of the community that has elected them.

==== TEI Technical Council Chair ====
The TEI Technical Council Chair's role is to administrate and facilitate the work of the TEI Technical Council. If all of the Council are the elected servants of the community, then the Council Chair is the servant of the servants of the TEI (''Servus servorum TEI''). The duties of the Technical Council Chair include (in no particular order):
* ensuring the delivery and maintenance of the Guidelines
* arranging for Council members to actively participate in Council activities
* arranging and chairing the face-to-face meetings (in conjunction with the local organiser)
* arranging and chairing the teleconferences
* creating agendas for those meetings, and ensuring minutes are written and posted of them
* assigning tickets in [http://github.com/TEIC/ the TEIC Github organization]
* acting as SIG coordinator
* liaising for and reporting on Council activities at all Board meetings
* reflecting Council wishes in Board discussions
* acting as a public point of contact and responding to technical enquiries (messages to council@tei-c.org are forwarded to the Council Chair)
* announcing new releases of the Guidelines on the TEI-L mailing list
* ensuring the smooth running of the TEI Technical Council

The TEI Technical Council Chair is also a member of the Council, so has all the duties and obligations of being a council member as well.

==== Release Technician ====
The TEI Guidelines release process (see [http://www.tei-c.org/Activities/Council/Working/tcw22.xml tcw22: Building a TEI Release]) involves a single individual responsible for 'pushing the button' and completing the steps required to make a TEI Guidelines release live. This is not a standing position; instead, the responsibility rotates for every release in order to demystify the release process and spread the expertise beyond Oxford staff. Although we have documented the work in quite a detailed manner, it is a non-trivial process and involves a fair degree of work. A release technician is usually required to set aside a whole day for the release process since history teaches us that often the entire process needs to be re-run to correct last-minute errors.

==== TEI-C Webmaster and Assistant Webmaster ====

The TEI-C Webmaster and Assistant Webmaster are not officially part of the Council but may be added to the mailing lists at the discretion of the Council Chair. They are responsible for the smooth running of the TEI-C Website.

=== How is the TEI Technical Council Chair elected? ===

The [http://www.tei-c.org/About/bylaws.xml#body.1_div.3_div.3 Bylaws of the TEI-C] say that:
<blockquote>
The Chair of the Technical Council shall be elected by the voting Members of the TEI-C Technical Council from its membership and shall serve as the chief technical officer of the Consortium. If no Technical Council Member is able or willing to assume the chair, the Technical Council may request the Board of Directors to second one of its elected members to the role, or it may nominate a non-elected individual.
</blockquote>
This leaves it intentionally vague as to the precise process the TEI Technical Council will follow. For now there is vague consensus that they will do something like the following. Note that timeframes below are not intended to be rigid or precise, but rather to be suggestive.
# The new Technical Council Members will be added to the tei-council (and tei-board-council) mailing lists shortly after the members' meeting. Up until around the last last Friday in November those who are Council members for next year will consider whether they want to run to be Chair of the TEI Technical Council. The current Chair will facilitate this process by answering any questions about the post. Before that date those intending to stand should send a statement of some sort to the Council mailing list detailing why they think the council members should vote for them.
# On or around the first weekday of December if only one person is running then the Chair will announce this to the tei-council mailing list as an acclamation (and after a short period for objections, to the Board and TEI-L). If multiple people are running, then the Council Chair will appoint a "returning officer" who is not a member of the incoming Council (i.e., not a voter and thus at least a somewhat disinterested party). The returning officer will set up an electronic voting system with the names of the candidates. This should be a private election with no one able to determine who has voted for whom. E.g. if using opavote.org this should have the following settings:
## Results only shown at end
## Method: "Plurality/FPTP/SNTV" for 2 candidates, "Instant Runoff Voting" for 3 or more
## a single winner
## Ballot type: "choose one" for 2 candidates, "ranked enhanced" for 3 or more
## candidate order shuffled
# The returning officer should ensure the election runs for at least 4 days, preferably in early December, after announcing it on the tei-council mailing list (and distributing ballots depending on the system).
# The results will be announced publicly on the tei-council mailing list, and Council members given a brief chance to raise any objections with the election before the current Chair informs the Board and announces it more publicly on TEI-L.
# The new Chair assumes the role on 1 January. The current chair steps down on 31 December. The outgoing and incoming chairs should co-ordinate activities between the election and 1 January so as to ensure a smooth transition. (Remembering that the current Chair might be departing off council at the end of that year.) These dates and timescales can of course shift and are not meant to be set in stone.

== Terminology ==

=== What was the War on Free-text-bearing Attribute Values? ===

The War on Free-text-bearing Attribute Values, also known as the War on Free-text-bearing Attributes and the War on Attributes for short, happened because some have felt that if attribute values don't have a datatype, they are more prone to abuse than if they did. So there has been an effort to give datatypes to as many attributes as possible. Some discussion of this with respect to @rend is available here: http://blogs.oucs.ox.ac.uk/jamesc/2011/12/01/rend-and-the-war-on-text-bearing-attributes/

=== What is the "Birnbaum doctrine"? ===

As expressed in [http://www.tei-c.org/Activities/Council/Working/tcw09.xml TCW09: Backward Compatibility and the Maintenance of the Text Encoding Initiative Guidelines], we should avoid breaking backward compatibility and only do so after serious consideration. It does not mean that we cannot break backwards compatibility, just that we've agreed a set of steps to take when we do so. Our deprecation policy supersedes some of this.

=== In what ways will Council break backwards compatibility? ===

For an egregious error, we might actually change a content model immediately. More often, we will survey the community on TEI-L before doing so, and we might [[Practices no longer recommended or now deprecated|deprecate]].

=== What is the "Durand Conundrum"? ===

The "Durand Conundrum" was suggested by David G. Durand concerning the TEI's decision to use the [[ODD | TEI ODD]] meta-schema language rather than just one of the existing schema languages. Given that we decided to use our own language, why use RelaxNG as part of that language for describing content models? Generally, the consensus is that [[ODD | TEI ODD]] gives us greater power and flexibility than any individual schema language can do in that we can model things that those schema languages are currently unable to cope with. TEI ODD gives the ability for a single document to produce both documentation and schema since these are inherently interlinked. It also keeps the TEI honest, in requiring it to use its own system to document schemas. [[ODD | TEI ODD]] does currently have some problems, a few of which are detailed at [[ODD-dev]] and successive revisions of TEI ODD are intended to solve some of these. Increasingly [[ODD#Future_plans:_.22Pure_ODD.22|the work on Pure ODD elements for content models and datatypes]] has cut the gordian knot of this problem.

=== What does "no magic" mean? ===

'Magic' in the sense sometimes used in Council discussion refers to pre-existing or special knowledge required to process something. For example, it was only by 'magic' that a TEI ODD processor would know to add attributes from the att.global attribute class to elements until this was changed to make all element specifications have to explicitly claim membership in this class if they wanted the global attributes. Knowing to add them was 'magic', and in general it is better if any requirements or understood knowledge is explicitly documented. While some 'magic' of understood conventions or processing will always remain in complex technical systems, the Council strives to at very least enable the possibility of documenting the underlying rules when it discovers them. James Cummings has been a fervent proponent of the removal of any understood 'magic' rules from the TEI.

=== What is a "magic token"? ===

This is an value, usually an attribute value, such as that of @key or @rend, which does not follow a standard outside vocabulary but instead is understood in some undocumented way and often used for local processing. It should usually be explained in the teiHeader if possible. Having any processing rely on undocumented magic tokens is generally considered a bad idea. See also [http://en.wikipedia.org/wiki/Magic_cookie Magic Cookie].

=== What is a non-deterministic content model? ===

If you have a content model for <a>:

<pre>
b*, c?, b*
</pre>

and you have a document with:

<pre>
<a>

</a>
</pre>

then a parser can't tell whether the matches the first b* or the second b* in the content model. Thus, the content model itself is called “non-deterministic”. DTDs and W3C XML Schemas reject non-deterministic content models. Thus, if we were to create one in the TEI, validation with DTD and XSD would fail due to errors ''in the schema'', regardless of whether the instance document has an occurence that is non-deterministic or not.

=== What are Janus elements? ===

These are pairs of elements that are in a sense two sides of the same coin, such as orig and reg, corr and sic, abbr and expan.

=== What does it mean to say that elements tessellate? ===

This means that all textual content is included in exactly one instance of an element. For example, once you start using divs (numbered or unnumbered), all text thereafter must be inside of one of the divs: you can't start using p elements that are not wrapped in a div.

In the Guidelines this is sometimes referred to as end-to-end segmentation.

== Meetings ==

=== Where are the minutes of previous meetings? ===

Minutes are [http://www.tei-c.org/Activities/Council/Meetings/index.xml archived on the TEI website]. Interim states of minutes may at times live in this wiki, Google Docs, or elsewhere.

=== How are the Council meetings held? ===

The Council usually makes use of Google Meet/Hangouts for their meetings. The meeting link will be in the agenda and/or sent out on the Council list before the meeting.

=== What funding is available for Council Activities? And how do I get reimbursed? ===

The TEI funds the participation of the council members in the meetings. Though I don't know of anyone claiming back telephone conferencing costs, I suppose that is possible as well, in most cases the council members' institutions probably swallow that.

If the council has a meeting, then the council members' travel, hotel, etc. will be reimbursed with proper receipts. The TEI reimburses all reasonable expenses in keeping with standard practice at most universities and granting agencies. We cover meals, travel, lodging, and other common daily travel expenses. Airfare should be economy class and direct return, unless otherwise arranged with the Treasurer prior to your trip. (See [http://www.tei-c.org/Board/procedures.xml#body.1_div.8 draft reimbursement policies and procedures].) If you have questions about reimbursement procedures, including what is reimbursable, please email John Unsworth, the TEI treasurer, at john.m.unsworth AT gmail.com.

Use the TEI Travel expense form available here: https://www.tei-c.org/wp-content/uploads/2017/10/TEI_travel_form.pdf '''Expense forms should be submitted within 10 days of the end of the meeting.'''

Council members are not funded to attend the TEI Members' Meeting, however, there has been discussion concerning whether the council should also officially meet here as well.

== How we get work done ==

=== I have something to say about a GitHub Feature Request or Bug: Should I comment on the issue or the TEI Council mailing list? ===

There is no hard-and-fast policy on this. The mailing list is a better place for ongoing discussions where people are arguing back and forth during decision making. The GitHub tracker is the appropriate place to record opinions, positions, and decisions for posterity, especially if such would help a) whoever is implementing the decisions recorded in the ticket, b) anyone revisiting this decision later to retrace the thinking. The [http://lists.tei-c.org/pipermail/tei-council/ TEI Council mailing list archives] are public, so if substantial discussion has taken place there (or indeed on TEI-L), this can also be linked to from the ticket.

=== When is discussion on an element or topic "closed" and how do I know? ===

Any topic can be revisited at any point, even in the published guidelines, through posting a feature request on GitHub. Council-specific issues should be raised on the council mailing list, after having reviewed any previous discussion on the topic in the [http://lists.tei-c.org/pipermail/tei-council/ tei-council mailing list archives].

=== How can I find out about every time a ticket is created or commented on? ===

Each repository has a "watch" control, which is to be found on the top right or the repo's GitHub page, below the navigation bar. This control lets you manage notifications in various ways.

=== How are tickets assigned in GitHub? ===
All members of Council are made part of the Council Team on the GitHub TEIC Organisation and meant to take an active role in the development and maintenance of the TEI Guidelines. This means that they have write access to the TEI Guidelines Github Repository, and tickets can be assigned to them in the ticket trackers. They can also update and modify tickets. This means that Council members are free to 'take' tickets which they wish to oversee. Other Council members can also 'give' tickets to each other if they think someone particularly suited to overseeing a particular ticket. (However, usually they should have the Council member's permission to do so.) On a regular basis the Council Chair will assign tickets to Council members, if a ticket gets assigned to them that they don't want to do they should tell the Chair and/or ask other Council members to swap.

=== What do the issue labels mean? ===

* 'Status: Blocked' means that the issue cannot be progressed because it requires either that another issue be completed first or that more information is needed from the reporter or a third party.

* 'Status: Needs Discussion' means that the issue has not been talked about enough yet to resolve it. New issues nearly always go into this status first. When Council has face-to-face meetings, these are usually the issues we target first.

* 'Status: Go' means that the ticket has been discussed, there is general consensus on what the correct thing to do is, and it has been assigned for someone to ensure its implementation.

* Other labels should be self-explanatory, and are sometimes created as needed to group tickets for various purposes.

=== How does a TEI release happen? ===

The process of making a release is documented at http://www.tei-c.org/Activities/Council/Working/tcw22.xml

== Working in GitHub ==

=== How do I edit the TEI Guidelines? ===

Editing the TEI Guidelines is a complex process and the Council has produced a document http://www.tei-c.org/Activities/Council/Working/tcw20.xml covering the logical and physical layout of the Guidelines, stylistic notes, how to make a change to the Guidelines (it requires [[TEI-Council-FAQ#How_do_I_use_GitHub.3F|using subversion]], building a release, and a reference section of useful information. If any information you need isn't in this document, ask on the Council list and get someone to update it!

=== How can I find out about every time a change is made in the TEI GitHub repository? ===
# Go to https://github.com/TEIC/
# Make sure you are logged in and
# go into each repository you are interested in and 'watch' them.

=== How do I use GitHub? ===
The TEI stores its working files in repositories in the [https://github.com/TEIC TEIC GitHub Organization]. See the [http://www.tei-c.org/guidelines/p5/using-the-tei-github-repository/ instructions]. Write access is reserved for those who are on the TEI Council or TEI Contributors teams. Any Council member should be able to add you to the Council team.

=== What should I put in a GitHub commit message? ===

It is beneficial to all those looking at the TEI GitHub repository if commit messages are clear and detailed. This is especially true when trying to revert changes made by yourself or others to solve problems. A good commit message will include:
* a subject line less than 72 characters long (which may be the whole message if no more is needed)
* an explanation to a useful level of detail about what you did
* a mention of why this is being done
* the GitHub issue numbers (or urls) that relate to the change if applicable
* an explanation of whether this change is completing the work described or one step towards doing so.

== TEI website ==

=== I want to add a document to add meeting minutes, reports, or working papers to the TEI-C website. How do I do that? ===

The TEI webmasters -- currently Kevin Hawkins and Nick Homenda -- have access to the CMS behind the TEI website. The site uses a stylesheet to render TEI Lite documents in XHTML, though the CMS can also deliver non-TEI documents. However, for long-term preservation and consistency, use of TEI Lite is encouraged.

You can author a document from scratch or take an existing document as a starting point. To get the XML source of an existing document, simply click "XML View" in the footer of a page on the TEI-C website and choose "save as" in your browser.

The TEI has a longstanding naming convention for files that consists of:

# a short alphabetical abbreviation for a committee (such as "tc" for "Technical Council")
# a one-letter abbreviation for minutes ("m"), reports ("r"), or working papers ("w")
# a two-digit number for the document with a committee series, numbered sequentially (e.g., "tcw01" is the first working paper from the Technical Council, "tcm05" is the fifth minutes from the Technical Council, etc.)

There is no registry of documents, so when creating a new one, you simply name the file appropriately.

Send the file to a webmaster for putting online. If you are hesitant to have the page go live until you have previewed it, you can ask the webmaster to send you a derived HTML version using the stylesheets without publishing that document.

=== How do I get access to the Google Analytics Data for www.tei-c.org? ===

Email the TEI-C webmaster: web@tei-c.org.

== Miscellaneous ==

=== Why do some elements have @type and others do not? ===

The TEI has avoided adding @type globally to elements because its availability is thought to invite tag or attribute abuse. In order for a request to add @type to an element to be considered for prolonged discussion and argument the TEI Technical Council has a standing principle that an element should be both repeatable and have obvious different classifications that apply to it. If such a request is approved then the preferred method is to make the element a member of the att.typed class (because if you can have @type, you can also have sub-types and thus need @subtype). If a closed or suggested value list, or different description is needed, this should then be provided as a local modification to the attributes inherited from att.typed.

== I have a question! ==

Then add it just above this one or email someone on the council or the council list reminding them of the existence of this wiki page when you ask your question.

[[Category:Council]]

TEI-Council-FAQ

2019-10-08T14:53:21Z

Hcayless: /* How does the Council do its work? */

So you have some questions about how the [[Council|TEI Technical Council]] works? This page has been set up to answer questions that new council members (or other curious parties) may have.

== Overview ==

=== How does the Council do its work? ===

By every means possible. These include monthly remote meetings, email, widely circulated discussion documents, and public debate in other contexts such as TEI-L and GitHub issues. The Council meets face to face twice a year (usually one of those meetings concurrent with the TEI Annual Meeting), and many more times than that virtually. Sub-groups of Council will often form around particularly large or complex issues and may meet separately to deal with them.

=== And what work does it do? ===

You should probably review the recent official work of the Council by reading the last few sets of minutes: http://www.tei-c.org/Council/ has an index page which links to them all (when we remember to update it). The minutes record topics discussed and responsibilities allocated at the Council level. Of course many Council members are also active in subgroups (formal or informal) of the Council or SIGs, which may be documented elsewhere as well.

Generally, things in Council work like this:

# A bug report or feature request is reported by anyone at [https://github.com/TEIC/ GitHub] for the [https://github.com/TEIC/TEI/issues Guidelines] or [https://github.com/TEIC/Stylesheets/issues Stylesheets].
# Sometimes others notice the ticket and comment on it.
# Sometimes a Council member may make an executive decision on the ticket. If it's a corrigible error or bug, we can just fix it in the appropriate ODD file(s) (also in GitHub). If it is not a real issue, sometimes the ticket will just be closed. If you do not have developer access on GitHub you'll to ask to be added to the Council team there. Otherwise, it's discussed either by email on the Council mailing list or at a Council meeting (conference call or in-person meeting). Comments are recorded in the ticket reflecting the decision reached, and changes are made in GitHub by a member of the Council sometime thereafter.
# The change shows up on tei-c.org after the next TEI "release", which happens about two or three times a year.

However, Council does sometimes consider lengthy proposals circulated to Council outside of GitHub and vote on them as packages, with the changes grouped together in a sensible way so they can be considered in smaller packages, or with the changes listed individually.

=== And what is its scope? ===

The Council's primary responsibility is to act as technical watchdog for the intellectual content of the TEI Guidelines. That is to say: it has the final say in just about every aspect of the TEI encoding scheme -- what elements exist in it, what they are called, how they should be used.

=== How do I join the TEI Council mailing list? ===

We have had the practice on the Council so far that elected members get added immediately to the list (and to the telecon, if there is one), with every right to participate, while outgoing members stay on until the end of their term. To join or discuss any problems using the list contact the [mailto:tei-council-owner@lists.tei-c.org TEI Council mailing list owner], currently this is Luis Meneses (Victoria). There is also a joint Board/Council mailing list to which you should be added as well.

=== Why are some people on the Council email list or attending Council meetings even though they are not on the list of elected members? ===

In addition to the members of the Council, the chair of the TEI Technical Council may invite others not elected to the Council to meetings (e.g. to speak to a particular issue). Historically the Council often invited a representative of the Board to the Council mailing list and meetings. The TEI-C Webmaster (currently Kevin Hawkins) and Assistant Webmaster (Nick Homenda) are also on the mailing lists.

=== What are the various job roles on the TEI Council? ===

==== TEI Technical Council Member ====
A TEI Technical Council Member is expected to participate in all aspects of Council work. This means that they should learn how the TEI infrastructure is organised and [http://www.tei-c.org/Activities/Council/Working/tcw20.xml how to edit the TEI Guidelines], asking on the Council list any questions they might have. They will be expected to come to face-to-face ("f2f") meetings (often two per year) and participate in a couple other teleconferences per year. They will be assigned (or take) feature requests/bugs on [https://github.com/TEIC the TEI Consortium's GitHub site], for which they will be in charge of encouraging discussion, reporting on the issue to Council, and eventually implementing (or ensuring implementation) of the resulting decision. A TEI Technical Council Member is expected to participate in the maintenance and development of the TEI Guidelines and related outputs. Some elected TEI Council members focus more on particular aspects of the infrastructure or stylesheets as part of the contribution to the Council. Council members should always act to represent what they believe are the opinions and best interest of the community that has elected them.

==== TEI Technical Council Chair ====
The TEI Technical Council Chair's role is to administrate and facilitate the work of the TEI Technical Council. If all of the Council are the elected servants of the community, then the Council Chair is the servant of the servants of the TEI (''Servus servorum TEI''). The duties of the Technical Council Chair include (in no particular order):
* ensuring the delivery and maintenance of the Guidelines
* arranging for Council members to actively participate in Council activities
* arranging and chairing the face-to-face meetings (in conjunction with the local organiser)
* arranging and chairing the teleconferences
* creating agendas for those meetings, and ensuring minutes are written and posted of them
* assigning tickets in [http://github.com/TEIC/ the TEIC Github organization]
* acting as SIG coordinator
* liaising for and reporting on Council activities at all Board meetings
* reflecting Council wishes in Board discussions
* acting as a public point of contact and responding to technical enquiries (messages to council@tei-c.org are forwarded to the Council Chair)
* announcing new releases of the Guidelines on the TEI-L mailing list
* ensuring the smooth running of the TEI Technical Council

The TEI Technical Council Chair is also a member of the Council, so has all the duties and obligations of being a council member as well.

==== Release Technician ====
The TEI Guidelines release process (see [http://www.tei-c.org/Activities/Council/Working/tcw22.xml tcw22: Building a TEI Release]) involves a single individual responsible for 'pushing the button' and completing the steps required to make a TEI Guidelines release live. This is not a standing position; instead, the responsibility rotates for every release in order to demystify the release process and spread the expertise beyond Oxford staff. Although we have documented the work in quite a detailed manner, it is a non-trivial process and involves a fair degree of work. A release technician is usually required to set aside a whole day for the release process since history teaches us that often the entire process needs to be re-run to correct last-minute errors.

==== TEI-C Webmaster and Assistant Webmaster ====

The TEI-C Webmaster and Assistant Webmaster are not officially part of the Council but may be added to the mailing lists at the discretion of the Council Chair. They are responsible for the smooth running of the TEI-C Website.

=== How is the TEI Technical Council Chair elected? ===

The [http://www.tei-c.org/About/bylaws.xml#body.1_div.3_div.3 Bylaws of the TEI-C] say that:
<blockquote>
The Chair of the Technical Council shall be elected by the voting Members of the TEI-C Technical Council from its membership and shall serve as the chief technical officer of the Consortium. If no Technical Council Member is able or willing to assume the chair, the Technical Council may request the Board of Directors to second one of its elected members to the role, or it may nominate a non-elected individual.
</blockquote>
This leaves it intentionally vague as to the precise process the TEI Technical Council will follow. For now there is vague consensus that they will do something like the following. Note that timeframes below are not intended to be rigid or precise, but rather to be suggestive.
# The new Technical Council Members will be added to the tei-council (and tei-board-council) mailing lists shortly after the members' meeting. Up until around the last last Friday in November those who are Council members for next year will consider whether they want to run to be Chair of the TEI Technical Council. The current Chair will facilitate this process by answering any questions about the post. Before that date those intending to stand should send a statement of some sort to the Council mailing list detailing why they think the council members should vote for them.
# On or around the first weekday of December if only one person is running then the Chair will announce this to the tei-council mailing list as an acclamation (and after a short period for objections, to the Board and TEI-L). If multiple people are running, then the Council Chair will appoint a "returning officer" who is not a member of the incoming Council (i.e., not a voter and thus at least a somewhat disinterested party). The returning officer will set up an electronic voting system with the names of the candidates. This should be a private election with no one able to determine who has voted for whom. E.g. if using opavote.org this should have the following settings:
## Results only shown at end
## Method: "Plurality/FPTP/SNTV" for 2 candidates, "Instant Runoff Voting" for 3 or more
## a single winner
## Ballot type: "choose one" for 2 candidates, "ranked enhanced" for 3 or more
## candidate order shuffled
# The returning officer should ensure the election runs for at least 4 days, preferably in early December, after announcing it on the tei-council mailing list (and distributing ballots depending on the system).
# The results will be announced publicly on the tei-council mailing list, and Council members given a brief chance to raise any objections with the election before the current Chair informs the Board and announces it more publicly on TEI-L.
# The new Chair assumes the role on 1 January. The current chair steps down on 31 December. The outgoing and incoming chairs should co-ordinate activities between the election and 1 January so as to ensure a smooth transition. (Remembering that the current Chair might be departing off council at the end of that year.) These dates and timescales can of course shift and are not meant to be set in stone.

== Terminology ==

=== What was the War on Free-text-bearing Attribute Values? ===

The War on Free-text-bearing Attribute Values, also known as the War on Free-text-bearing Attributes and the War on Attributes for short, happened because some have felt that if attribute values don't have a datatype, they are more prone to abuse than if they did. So there has been an effort to give datatypes to as many attributes as possible. Some discussion of this with respect to @rend is available here: http://blogs.oucs.ox.ac.uk/jamesc/2011/12/01/rend-and-the-war-on-text-bearing-attributes/

=== What is the "Birnbaum doctrine"? ===

As expressed in [http://www.tei-c.org/Activities/Council/Working/tcw09.xml TCW09: Backward Compatibility and the Maintenance of the Text Encoding Initiative Guidelines], we should avoid breaking backward compatibility and only do so after serious consideration. It does not mean that we cannot break backwards compatibility, just that we've agreed a set of steps to take when we do so. Our deprecation policy supersedes some of this.

=== In what ways will Council break backwards compatibility? ===

For an egregious error, we might actually change a content model immediately. More often, we will survey the community on TEI-L before doing so, and we might [[Practices no longer recommended or now deprecated|deprecate]].

=== What is the "Durand Conundrum"? ===

The "Durand Conundrum" was suggested by David G. Durand concerning the TEI's decision to use the [[ODD | TEI ODD]] meta-schema language rather than just one of the existing schema languages. Given that we decided to use our own language, why use RelaxNG as part of that language for describing content models? Generally, the consensus is that [[ODD | TEI ODD]] gives us greater power and flexibility than any individual schema language can do in that we can model things that those schema languages are currently unable to cope with. TEI ODD gives the ability for a single document to produce both documentation and schema since these are inherently interlinked. It also keeps the TEI honest, in requiring it to use its own system to document schemas. [[ODD | TEI ODD]] does currently have some problems, a few of which are detailed at [[ODD-dev]] and successive revisions of TEI ODD are intended to solve some of these. Increasingly [[ODD#Future_plans:_.22Pure_ODD.22|the work on Pure ODD elements for content models and datatypes]] has cut the gordian knot of this problem.

=== What does "no magic" mean? ===

'Magic' in the sense sometimes used in Council discussion refers to pre-existing or special knowledge required to process something. For example, it was only by 'magic' that a TEI ODD processor would know to add attributes from the att.global attribute class to elements until this was changed to make all element specifications have to explicitly claim membership in this class if they wanted the global attributes. Knowing to add them was 'magic', and in general it is better if any requirements or understood knowledge is explicitly documented. While some 'magic' of understood conventions or processing will always remain in complex technical systems, the Council strives to at very least enable the possibility of documenting the underlying rules when it discovers them. James Cummings has been a fervent proponent of the removal of any understood 'magic' rules from the TEI.

=== What is a "magic token"? ===

This is an value, usually an attribute value, such as that of @key or @rend, which does not follow a standard outside vocabulary but instead is understood in some undocumented way and often used for local processing. It should usually be explained in the teiHeader if possible. Having any processing rely on undocumented magic tokens is generally considered a bad idea. See also [http://en.wikipedia.org/wiki/Magic_cookie Magic Cookie].

=== What is a non-deterministic content model? ===

If you have a content model for <a>:

<pre>
b*, c?, b*
</pre>

and you have a document with:

<pre>
<a>

</a>
</pre>

then a parser can't tell whether the matches the first b* or the second b* in the content model. Thus, the content model itself is called “non-deterministic”. DTDs and W3C XML Schemas reject non-deterministic content models. Thus, if we were to create one in the TEI, validation with DTD and XSD would fail due to errors ''in the schema'', regardless of whether the instance document has an occurence that is non-deterministic or not.

=== What are Janus elements? ===

These are pairs of elements that are in a sense two sides of the same coin, such as orig and reg, corr and sic, abbr and expan.

=== What does it mean to say that elements tessellate? ===

This means that all textual content is included in exactly one instance of an element. For example, once you start using divs (numbered or unnumbered), all text thereafter must be inside of one of the divs: you can't start using p elements that are not wrapped in a div.

In the Guidelines this is sometimes referred to as end-to-end segmentation.

== Meetings ==

=== Where are the minutes of previous meetings? ===

Minutes are [http://www.tei-c.org/Activities/Council/Meetings/index.xml archived on the TEI website]. Interim states of minutes may at times live in this wiki, Google Docs, or elsewhere.

=== How are the Council meetings held? ===

The Council usually makes use of Google Meet/Hangouts for their meetings. The meeting link will be in the agenda and/or sent out on the Council list before the meeting.

=== What funding is available for Council Activities? And how do I get reimbursed? ===

The TEI funds the participation of the council members in the meetings. Though I don't know of anyone claiming back telephone conferencing costs, I suppose that is possible as well, in most cases the council members' institutions probably swallow that.

If the council has a meeting, then the council members' travel, hotel, etc. will be reimbursed with proper receipts. The TEI reimburses all reasonable expenses in keeping with standard practice at most universities and granting agencies. We cover meals, travel, lodging, and other common daily travel expenses. Airfare should be economy class and direct return, unless otherwise arranged with the Treasurer prior to your trip. (See [http://www.tei-c.org/Board/procedures.xml#body.1_div.8 draft reimbursement policies and procedures].) If you have questions about reimbursement procedures, including what is reimbursable, please email John Unsworth, the TEI treasurer, at john.m.unsworth AT gmail.com.

Use the TEI Travel expense form available here: https://www.tei-c.org/wp-content/uploads/2017/10/TEI_travel_form.pdf '''Expense forms should be submitted within 10 days of the end of the meeting.'''

Council members are not funded to attend the TEI Members' Meeting, however, there has been discussion concerning whether the council should also officially meet here as well.

== How we get work done ==

=== I have something to say about a GitHub Feature Request or Bug: Should I comment on the issue or the TEI Council mailing list? ===

There is no hard-and-fast policy on this. The mailing list is a better place for ongoing discussions where people are arguing back and forth during decision making. The GitHub tracker is the appropriate place to record opinions, positions, and decisions for posterity, especially if such would help a) whoever is implementing the decisions recorded in the ticket, b) anyone revisiting this decision later to retrace the thinking. The [http://lists.tei-c.org/pipermail/tei-council/ TEI Council mailing list archives] are public, so if substantial discussion has taken place there (or indeed on TEI-L), this can also be linked to from the ticket.

=== When is discussion on an element or topic "closed" and how do I know? ===

Any topic can be revisited at any point, even in the published guidelines, through posting a feature request on GitHub. Council-specific issues should be raised on the council mailing list, after having reviewed any previous discussion on the topic in the [http://lists.tei-c.org/pipermail/tei-council/ tei-council mailing list archives].

=== How can I find out about every time a ticket is created or commented on? ===

Each repository has a "watch" control, which is to be found on the top right or the repo's GitHub page, below the navigation bar. This control lets you manage notifications in various ways.

=== How are tickets assigned in GitHub? ===
All members of Council are made part of the Council Team on the GitHub TEIC Organisation and meant to take an active role in the development and maintenance of the TEI Guidelines. This means that they have write access to the TEI Guidelines Github Repository, and tickets can be assigned to them in the ticket trackers. They can also update and modify tickets. This means that Council members are free to 'take' tickets which they wish to oversee. Other Council members can also 'give' tickets to each other if they think someone particularly suited to overseeing a particular ticket. (However, usually they should have the Council member's permission to do so.) On a regular basis the Council Chair will assign tickets to Council members, if a ticket gets assigned to them that they don't want to do they should tell the Chair and/or ask other Council members to swap.

=== What do the issue labels mean? ===

* 'Status: Blocked' means that the issue cannot be progressed because it requires either that another issue be completed first or that more information is needed from the reporter or a third party.

* 'Status: Needs Discussion' means that the issue has not been talked about enough yet to resolve it. New issues nearly always go into this status first. When Council has face-to-face meetings, these are usually the issues we target first.

* 'Status: Go' means that the ticket has been discussed, there is general consensus on what the correct thing to do is, and it has been assigned for someone to ensure its implementation.

* Other labels should be self-explanatory, and are sometimes created as needed to group tickets for various purposes.

=== How does a TEI release happen? ===

The process of making a release is documented at http://www.tei-c.org/Activities/Council/Working/tcw22.xml

== Working in GitHub ==

=== How do I edit the TEI Guidelines? ===

Editing the TEI Guidelines is a complex process and the Council has produced a document http://www.tei-c.org/Activities/Council/Working/tcw20.xml covering the logical and physical layout of the Guidelines, stylistic notes, how to make a change to the Guidelines (it requires [[TEI-Council-FAQ#How_do_I_use_GitHub.3F|using subversion]], building a release, and a reference section of useful information. If any information you need isn't in this document, ask on the Council list and get someone to update it!

=== How can I find out about every time a change is made in the TEI GitHub repository? ===
# Go to https://github.com/TEIC/
# Make sure you are logged in and
# go into each repository you are interested in and 'watch' them.

=== How do I use GitHub? ===
The TEI stores its working files in repositories in the [https://github.com/TEIC TEIC GitHub Organization]. See the [http://www.tei-c.org/guidelines/p5/using-the-tei-github-repository/ instructions]. Write access is reserved for those who are on the TEI Council or TEI Contributors teams. Any Council member should be able to add you to the Council team.

=== What should I put in a GitHub commit message? ===

It is beneficial to all those looking at the TEI GitHub repository if commit messages are clear and detailed. This is especially true when trying to revert changes made by yourself or others to solve problems. A good commit message will include:
* a subject line less than 72 characters long (which may be the whole message if no more is needed)
* an explanation to a useful level of detail about what you did
* a mention of why this is being done
* the GitHub issue numbers (or urls) that relate to the change if applicable
* an explanation of whether this change is completing the work described or one step towards doing so.

== TEI website ==

=== I want to add a document to add meeting minutes, reports, or working papers to the TEI-C website. How do I do that? ===

The TEI webmasters -- currently Kevin Hawkins and Nick Homenda -- have access to the CMS behind the TEI website. The site uses a stylesheet to render TEI Lite documents in XHTML, though the CMS can also deliver non-TEI documents. However, for long-term preservation and consistency, use of TEI Lite is encouraged.

You can author a document from scratch or take an existing document as a starting point. To get the XML source of an existing document, simply click "XML View" in the footer of a page on the TEI-C website and choose "save as" in your browser.

The TEI has a longstanding naming convention for files that consists of:

# a short alphabetical abbreviation for a committee (such as "tc" for "Technical Council")
# a one-letter abbreviation for minutes ("m"), reports ("r"), or working papers ("w")
# a two-digit number for the document with a committee series, numbered sequentially (e.g., "tcw01" is the first working paper from the Technical Council, "tcm05" is the fifth minutes from the Technical Council, etc.)

There is no registry of documents, so when creating a new one, you simply name the file appropriately.

Send the file to a webmaster for putting online. If you are hesitant to have the page go live until you have previewed it, you can ask the webmaster to send you a derived HTML version using the stylesheets without publishing that document.

=== How do I get access to the Google Analytics Data for www.tei-c.org? ===

Email the TEI-C webmaster: web@tei-c.org.

== Miscellaneous ==

=== Why do some elements have @type and others do not? ===

The TEI has avoided adding @type globally to elements because its availability is thought to invite tag or attribute abuse. In order for a request to add @type to an element to be considered for prolonged discussion and argument the TEI Technical Council has a standing principle that an element should be both repeatable and have obvious different classifications that apply to it. If such a request is approved then the preferred method is to make the element a member of the att.typed class (because if you can have @type, you can also have sub-types and thus need @subtype). If a closed or suggested value list, or different description is needed, this should then be provided as a local modification to the attributes inherited from att.typed.

== I have a question! ==

Then add it just above this one or email someone on the council or the council list reminding them of the existence of this wiki page when you ask your question.

[[Category:Council]]

TEI-Council-FAQ

2019-10-08T14:50:29Z

Hcayless: /* How do I join the TEI Council mailing list? */

So you have some questions about how the [[Council|TEI Technical Council]] works? This page has been set up to answer questions that new council members (or other curious parties) may have.

== Overview ==

=== How does the Council do its work? ===

By every means possible. These include monthly remote meetings, email, widely circulated discussion documents, and public debate in other contexts such as TEI-L and GitHub issues. The Council meets face to face twice a year (usually one of those meetings concurrent with the TEI Annual Meeting), and many more times than that virtually.

=== And what work does it do? ===

You should probably review the recent official work of the Council by reading the last few sets of minutes: http://www.tei-c.org/Council/ has an index page which links to them all (when we remember to update it). The minutes record topics discussed and responsibilities allocated at the Council level. Of course many Council members are also active in subgroups (formal or informal) of the Council or SIGs, which may be documented elsewhere as well.

Generally, things in Council work like this:

# A bug report or feature request is reported by anyone at [https://github.com/TEIC/ GitHub] for the [https://github.com/TEIC/TEI/issues Guidelines] or [https://github.com/TEIC/Stylesheets/issues Stylesheets].
# Sometimes others notice the ticket and comment on it.
# Sometimes a Council member may make an executive decision on the ticket. If it's a corrigible error or bug, we can just fix it in the appropriate ODD file(s) (also in GitHub). If it is not a real issue, sometimes the ticket will just be closed. If you do not have developer access on GitHub you'll to ask to be added to the Council team there. Otherwise, it's discussed either by email on the Council mailing list or at a Council meeting (conference call or in-person meeting). Comments are recorded in the ticket reflecting the decision reached, and changes are made in GitHub by a member of the Council sometime thereafter.
# The change shows up on tei-c.org after the next TEI "release", which happens about two or three times a year.

However, Council does sometimes consider lengthy proposals circulated to Council outside of GitHub and vote on them as packages, with the changes grouped together in a sensible way so they can be considered in smaller packages, or with the changes listed individually.

=== And what is its scope? ===

The Council's primary responsibility is to act as technical watchdog for the intellectual content of the TEI Guidelines. That is to say: it has the final say in just about every aspect of the TEI encoding scheme -- what elements exist in it, what they are called, how they should be used.

=== How do I join the TEI Council mailing list? ===

We have had the practice on the Council so far that elected members get added immediately to the list (and to the telecon, if there is one), with every right to participate, while outgoing members stay on until the end of their term. To join or discuss any problems using the list contact the [mailto:tei-council-owner@lists.tei-c.org TEI Council mailing list owner], currently this is Luis Meneses (Victoria). There is also a joint Board/Council mailing list to which you should be added as well.

=== Why are some people on the Council email list or attending Council meetings even though they are not on the list of elected members? ===

In addition to the members of the Council, the chair of the TEI Technical Council may invite others not elected to the Council to meetings (e.g. to speak to a particular issue). Historically the Council often invited a representative of the Board to the Council mailing list and meetings. The TEI-C Webmaster (currently Kevin Hawkins) and Assistant Webmaster (Nick Homenda) are also on the mailing lists.

=== What are the various job roles on the TEI Council? ===

==== TEI Technical Council Member ====
A TEI Technical Council Member is expected to participate in all aspects of Council work. This means that they should learn how the TEI infrastructure is organised and [http://www.tei-c.org/Activities/Council/Working/tcw20.xml how to edit the TEI Guidelines], asking on the Council list any questions they might have. They will be expected to come to face-to-face ("f2f") meetings (often two per year) and participate in a couple other teleconferences per year. They will be assigned (or take) feature requests/bugs on [https://github.com/TEIC the TEI Consortium's GitHub site], for which they will be in charge of encouraging discussion, reporting on the issue to Council, and eventually implementing (or ensuring implementation) of the resulting decision. A TEI Technical Council Member is expected to participate in the maintenance and development of the TEI Guidelines and related outputs. Some elected TEI Council members focus more on particular aspects of the infrastructure or stylesheets as part of the contribution to the Council. Council members should always act to represent what they believe are the opinions and best interest of the community that has elected them.

==== TEI Technical Council Chair ====
The TEI Technical Council Chair's role is to administrate and facilitate the work of the TEI Technical Council. If all of the Council are the elected servants of the community, then the Council Chair is the servant of the servants of the TEI (''Servus servorum TEI''). The duties of the Technical Council Chair include (in no particular order):
* ensuring the delivery and maintenance of the Guidelines
* arranging for Council members to actively participate in Council activities
* arranging and chairing the face-to-face meetings (in conjunction with the local organiser)
* arranging and chairing the teleconferences
* creating agendas for those meetings, and ensuring minutes are written and posted of them
* assigning tickets in [http://github.com/TEIC/ the TEIC Github organization]
* acting as SIG coordinator
* liaising for and reporting on Council activities at all Board meetings
* reflecting Council wishes in Board discussions
* acting as a public point of contact and responding to technical enquiries (messages to council@tei-c.org are forwarded to the Council Chair)
* announcing new releases of the Guidelines on the TEI-L mailing list
* ensuring the smooth running of the TEI Technical Council

The TEI Technical Council Chair is also a member of the Council, so has all the duties and obligations of being a council member as well.

==== Release Technician ====
The TEI Guidelines release process (see [http://www.tei-c.org/Activities/Council/Working/tcw22.xml tcw22: Building a TEI Release]) involves a single individual responsible for 'pushing the button' and completing the steps required to make a TEI Guidelines release live. This is not a standing position; instead, the responsibility rotates for every release in order to demystify the release process and spread the expertise beyond Oxford staff. Although we have documented the work in quite a detailed manner, it is a non-trivial process and involves a fair degree of work. A release technician is usually required to set aside a whole day for the release process since history teaches us that often the entire process needs to be re-run to correct last-minute errors.

==== TEI-C Webmaster and Assistant Webmaster ====

The TEI-C Webmaster and Assistant Webmaster are not officially part of the Council but may be added to the mailing lists at the discretion of the Council Chair. They are responsible for the smooth running of the TEI-C Website.

=== How is the TEI Technical Council Chair elected? ===

The [http://www.tei-c.org/About/bylaws.xml#body.1_div.3_div.3 Bylaws of the TEI-C] say that:
<blockquote>
The Chair of the Technical Council shall be elected by the voting Members of the TEI-C Technical Council from its membership and shall serve as the chief technical officer of the Consortium. If no Technical Council Member is able or willing to assume the chair, the Technical Council may request the Board of Directors to second one of its elected members to the role, or it may nominate a non-elected individual.
</blockquote>
This leaves it intentionally vague as to the precise process the TEI Technical Council will follow. For now there is vague consensus that they will do something like the following. Note that timeframes below are not intended to be rigid or precise, but rather to be suggestive.
# The new Technical Council Members will be added to the tei-council (and tei-board-council) mailing lists shortly after the members' meeting. Up until around the last last Friday in November those who are Council members for next year will consider whether they want to run to be Chair of the TEI Technical Council. The current Chair will facilitate this process by answering any questions about the post. Before that date those intending to stand should send a statement of some sort to the Council mailing list detailing why they think the council members should vote for them.
# On or around the first weekday of December if only one person is running then the Chair will announce this to the tei-council mailing list as an acclamation (and after a short period for objections, to the Board and TEI-L). If multiple people are running, then the Council Chair will appoint a "returning officer" who is not a member of the incoming Council (i.e., not a voter and thus at least a somewhat disinterested party). The returning officer will set up an electronic voting system with the names of the candidates. This should be a private election with no one able to determine who has voted for whom. E.g. if using opavote.org this should have the following settings:
## Results only shown at end
## Method: "Plurality/FPTP/SNTV" for 2 candidates, "Instant Runoff Voting" for 3 or more
## a single winner
## Ballot type: "choose one" for 2 candidates, "ranked enhanced" for 3 or more
## candidate order shuffled
# The returning officer should ensure the election runs for at least 4 days, preferably in early December, after announcing it on the tei-council mailing list (and distributing ballots depending on the system).
# The results will be announced publicly on the tei-council mailing list, and Council members given a brief chance to raise any objections with the election before the current Chair informs the Board and announces it more publicly on TEI-L.
# The new Chair assumes the role on 1 January. The current chair steps down on 31 December. The outgoing and incoming chairs should co-ordinate activities between the election and 1 January so as to ensure a smooth transition. (Remembering that the current Chair might be departing off council at the end of that year.) These dates and timescales can of course shift and are not meant to be set in stone.

== Terminology ==

=== What was the War on Free-text-bearing Attribute Values? ===

The War on Free-text-bearing Attribute Values, also known as the War on Free-text-bearing Attributes and the War on Attributes for short, happened because some have felt that if attribute values don't have a datatype, they are more prone to abuse than if they did. So there has been an effort to give datatypes to as many attributes as possible. Some discussion of this with respect to @rend is available here: http://blogs.oucs.ox.ac.uk/jamesc/2011/12/01/rend-and-the-war-on-text-bearing-attributes/

=== What is the "Birnbaum doctrine"? ===

As expressed in [http://www.tei-c.org/Activities/Council/Working/tcw09.xml TCW09: Backward Compatibility and the Maintenance of the Text Encoding Initiative Guidelines], we should avoid breaking backward compatibility and only do so after serious consideration. It does not mean that we cannot break backwards compatibility, just that we've agreed a set of steps to take when we do so. Our deprecation policy supersedes some of this.

=== In what ways will Council break backwards compatibility? ===

For an egregious error, we might actually change a content model immediately. More often, we will survey the community on TEI-L before doing so, and we might [[Practices no longer recommended or now deprecated|deprecate]].

=== What is the "Durand Conundrum"? ===

The "Durand Conundrum" was suggested by David G. Durand concerning the TEI's decision to use the [[ODD | TEI ODD]] meta-schema language rather than just one of the existing schema languages. Given that we decided to use our own language, why use RelaxNG as part of that language for describing content models? Generally, the consensus is that [[ODD | TEI ODD]] gives us greater power and flexibility than any individual schema language can do in that we can model things that those schema languages are currently unable to cope with. TEI ODD gives the ability for a single document to produce both documentation and schema since these are inherently interlinked. It also keeps the TEI honest, in requiring it to use its own system to document schemas. [[ODD | TEI ODD]] does currently have some problems, a few of which are detailed at [[ODD-dev]] and successive revisions of TEI ODD are intended to solve some of these. Increasingly [[ODD#Future_plans:_.22Pure_ODD.22|the work on Pure ODD elements for content models and datatypes]] has cut the gordian knot of this problem.

=== What does "no magic" mean? ===

'Magic' in the sense sometimes used in Council discussion refers to pre-existing or special knowledge required to process something. For example, it was only by 'magic' that a TEI ODD processor would know to add attributes from the att.global attribute class to elements until this was changed to make all element specifications have to explicitly claim membership in this class if they wanted the global attributes. Knowing to add them was 'magic', and in general it is better if any requirements or understood knowledge is explicitly documented. While some 'magic' of understood conventions or processing will always remain in complex technical systems, the Council strives to at very least enable the possibility of documenting the underlying rules when it discovers them. James Cummings has been a fervent proponent of the removal of any understood 'magic' rules from the TEI.

=== What is a "magic token"? ===

This is an value, usually an attribute value, such as that of @key or @rend, which does not follow a standard outside vocabulary but instead is understood in some undocumented way and often used for local processing. It should usually be explained in the teiHeader if possible. Having any processing rely on undocumented magic tokens is generally considered a bad idea. See also [http://en.wikipedia.org/wiki/Magic_cookie Magic Cookie].

=== What is a non-deterministic content model? ===

If you have a content model for <a>:

<pre>
b*, c?, b*
</pre>

and you have a document with:

<pre>
<a>

</a>
</pre>

then a parser can't tell whether the matches the first b* or the second b* in the content model. Thus, the content model itself is called “non-deterministic”. DTDs and W3C XML Schemas reject non-deterministic content models. Thus, if we were to create one in the TEI, validation with DTD and XSD would fail due to errors ''in the schema'', regardless of whether the instance document has an occurence that is non-deterministic or not.

=== What are Janus elements? ===

These are pairs of elements that are in a sense two sides of the same coin, such as orig and reg, corr and sic, abbr and expan.

=== What does it mean to say that elements tessellate? ===

This means that all textual content is included in exactly one instance of an element. For example, once you start using divs (numbered or unnumbered), all text thereafter must be inside of one of the divs: you can't start using p elements that are not wrapped in a div.

In the Guidelines this is sometimes referred to as end-to-end segmentation.

== Meetings ==

=== Where are the minutes of previous meetings? ===

Minutes are [http://www.tei-c.org/Activities/Council/Meetings/index.xml archived on the TEI website]. Interim states of minutes may at times live in this wiki, Google Docs, or elsewhere.

=== How are the Council meetings held? ===

The Council usually makes use of Google Meet/Hangouts for their meetings. The meeting link will be in the agenda and/or sent out on the Council list before the meeting.

=== What funding is available for Council Activities? And how do I get reimbursed? ===

The TEI funds the participation of the council members in the meetings. Though I don't know of anyone claiming back telephone conferencing costs, I suppose that is possible as well, in most cases the council members' institutions probably swallow that.

If the council has a meeting, then the council members' travel, hotel, etc. will be reimbursed with proper receipts. The TEI reimburses all reasonable expenses in keeping with standard practice at most universities and granting agencies. We cover meals, travel, lodging, and other common daily travel expenses. Airfare should be economy class and direct return, unless otherwise arranged with the Treasurer prior to your trip. (See [http://www.tei-c.org/Board/procedures.xml#body.1_div.8 draft reimbursement policies and procedures].) If you have questions about reimbursement procedures, including what is reimbursable, please email John Unsworth, the TEI treasurer, at john.m.unsworth AT gmail.com.

Use the TEI Travel expense form available here: https://www.tei-c.org/wp-content/uploads/2017/10/TEI_travel_form.pdf '''Expense forms should be submitted within 10 days of the end of the meeting.'''

Council members are not funded to attend the TEI Members' Meeting, however, there has been discussion concerning whether the council should also officially meet here as well.

== How we get work done ==

=== I have something to say about a GitHub Feature Request or Bug: Should I comment on the issue or the TEI Council mailing list? ===

There is no hard-and-fast policy on this. The mailing list is a better place for ongoing discussions where people are arguing back and forth during decision making. The GitHub tracker is the appropriate place to record opinions, positions, and decisions for posterity, especially if such would help a) whoever is implementing the decisions recorded in the ticket, b) anyone revisiting this decision later to retrace the thinking. The [http://lists.tei-c.org/pipermail/tei-council/ TEI Council mailing list archives] are public, so if substantial discussion has taken place there (or indeed on TEI-L), this can also be linked to from the ticket.

=== When is discussion on an element or topic "closed" and how do I know? ===

Any topic can be revisited at any point, even in the published guidelines, through posting a feature request on GitHub. Council-specific issues should be raised on the council mailing list, after having reviewed any previous discussion on the topic in the [http://lists.tei-c.org/pipermail/tei-council/ tei-council mailing list archives].

=== How can I find out about every time a ticket is created or commented on? ===

Each repository has a "watch" control, which is to be found on the top right or the repo's GitHub page, below the navigation bar. This control lets you manage notifications in various ways.

=== How are tickets assigned in GitHub? ===
All members of Council are made part of the Council Team on the GitHub TEIC Organisation and meant to take an active role in the development and maintenance of the TEI Guidelines. This means that they have write access to the TEI Guidelines Github Repository, and tickets can be assigned to them in the ticket trackers. They can also update and modify tickets. This means that Council members are free to 'take' tickets which they wish to oversee. Other Council members can also 'give' tickets to each other if they think someone particularly suited to overseeing a particular ticket. (However, usually they should have the Council member's permission to do so.) On a regular basis the Council Chair will assign tickets to Council members, if a ticket gets assigned to them that they don't want to do they should tell the Chair and/or ask other Council members to swap.

=== What do the issue labels mean? ===

* 'Status: Blocked' means that the issue cannot be progressed because it requires either that another issue be completed first or that more information is needed from the reporter or a third party.

* 'Status: Needs Discussion' means that the issue has not been talked about enough yet to resolve it. New issues nearly always go into this status first. When Council has face-to-face meetings, these are usually the issues we target first.

* 'Status: Go' means that the ticket has been discussed, there is general consensus on what the correct thing to do is, and it has been assigned for someone to ensure its implementation.

* Other labels should be self-explanatory, and are sometimes created as needed to group tickets for various purposes.

=== How does a TEI release happen? ===

The process of making a release is documented at http://www.tei-c.org/Activities/Council/Working/tcw22.xml

== Working in GitHub ==

=== How do I edit the TEI Guidelines? ===

Editing the TEI Guidelines is a complex process and the Council has produced a document http://www.tei-c.org/Activities/Council/Working/tcw20.xml covering the logical and physical layout of the Guidelines, stylistic notes, how to make a change to the Guidelines (it requires [[TEI-Council-FAQ#How_do_I_use_GitHub.3F|using subversion]], building a release, and a reference section of useful information. If any information you need isn't in this document, ask on the Council list and get someone to update it!

=== How can I find out about every time a change is made in the TEI GitHub repository? ===
# Go to https://github.com/TEIC/
# Make sure you are logged in and
# go into each repository you are interested in and 'watch' them.

=== How do I use GitHub? ===
The TEI stores its working files in repositories in the [https://github.com/TEIC TEIC GitHub Organization]. See the [http://www.tei-c.org/guidelines/p5/using-the-tei-github-repository/ instructions]. Write access is reserved for those who are on the TEI Council or TEI Contributors teams. Any Council member should be able to add you to the Council team.

=== What should I put in a GitHub commit message? ===

It is beneficial to all those looking at the TEI GitHub repository if commit messages are clear and detailed. This is especially true when trying to revert changes made by yourself or others to solve problems. A good commit message will include:
* a subject line less than 72 characters long (which may be the whole message if no more is needed)
* an explanation to a useful level of detail about what you did
* a mention of why this is being done
* the GitHub issue numbers (or urls) that relate to the change if applicable
* an explanation of whether this change is completing the work described or one step towards doing so.

== TEI website ==

=== I want to add a document to add meeting minutes, reports, or working papers to the TEI-C website. How do I do that? ===

The TEI webmasters -- currently Kevin Hawkins and Nick Homenda -- have access to the CMS behind the TEI website. The site uses a stylesheet to render TEI Lite documents in XHTML, though the CMS can also deliver non-TEI documents. However, for long-term preservation and consistency, use of TEI Lite is encouraged.

You can author a document from scratch or take an existing document as a starting point. To get the XML source of an existing document, simply click "XML View" in the footer of a page on the TEI-C website and choose "save as" in your browser.

The TEI has a longstanding naming convention for files that consists of:

# a short alphabetical abbreviation for a committee (such as "tc" for "Technical Council")
# a one-letter abbreviation for minutes ("m"), reports ("r"), or working papers ("w")
# a two-digit number for the document with a committee series, numbered sequentially (e.g., "tcw01" is the first working paper from the Technical Council, "tcm05" is the fifth minutes from the Technical Council, etc.)

There is no registry of documents, so when creating a new one, you simply name the file appropriately.

Send the file to a webmaster for putting online. If you are hesitant to have the page go live until you have previewed it, you can ask the webmaster to send you a derived HTML version using the stylesheets without publishing that document.

=== How do I get access to the Google Analytics Data for www.tei-c.org? ===

Email the TEI-C webmaster: web@tei-c.org.

== Miscellaneous ==

=== Why do some elements have @type and others do not? ===

The TEI has avoided adding @type globally to elements because its availability is thought to invite tag or attribute abuse. In order for a request to add @type to an element to be considered for prolonged discussion and argument the TEI Technical Council has a standing principle that an element should be both repeatable and have obvious different classifications that apply to it. If such a request is approved then the preferred method is to make the element a member of the att.typed class (because if you can have @type, you can also have sub-types and thus need @subtype). If a closed or suggested value list, or different description is needed, this should then be provided as a local modification to the attributes inherited from att.typed.

== I have a question! ==

Then add it just above this one or email someone on the council or the council list reminding them of the existence of this wiki page when you ask your question.

[[Category:Council]]

TEI-Council-FAQ

2019-10-08T14:48:51Z

Hcayless: /* How does the Council do its work? */

So you have some questions about how the [[Council|TEI Technical Council]] works? This page has been set up to answer questions that new council members (or other curious parties) may have.

== Overview ==

=== How does the Council do its work? ===

By every means possible. These include monthly remote meetings, email, widely circulated discussion documents, and public debate in other contexts such as TEI-L and GitHub issues. The Council meets face to face twice a year (usually one of those meetings concurrent with the TEI Annual Meeting), and many more times than that virtually.

=== And what work does it do? ===

You should probably review the recent official work of the Council by reading the last few sets of minutes: http://www.tei-c.org/Council/ has an index page which links to them all (when we remember to update it). The minutes record topics discussed and responsibilities allocated at the Council level. Of course many Council members are also active in subgroups (formal or informal) of the Council or SIGs, which may be documented elsewhere as well.

Generally, things in Council work like this:

# A bug report or feature request is reported by anyone at [https://github.com/TEIC/ GitHub] for the [https://github.com/TEIC/TEI/issues Guidelines] or [https://github.com/TEIC/Stylesheets/issues Stylesheets].
# Sometimes others notice the ticket and comment on it.
# Sometimes a Council member may make an executive decision on the ticket. If it's a corrigible error or bug, we can just fix it in the appropriate ODD file(s) (also in GitHub). If it is not a real issue, sometimes the ticket will just be closed. If you do not have developer access on GitHub you'll to ask to be added to the Council team there. Otherwise, it's discussed either by email on the Council mailing list or at a Council meeting (conference call or in-person meeting). Comments are recorded in the ticket reflecting the decision reached, and changes are made in GitHub by a member of the Council sometime thereafter.
# The change shows up on tei-c.org after the next TEI "release", which happens about two or three times a year.

However, Council does sometimes consider lengthy proposals circulated to Council outside of GitHub and vote on them as packages, with the changes grouped together in a sensible way so they can be considered in smaller packages, or with the changes listed individually.

=== And what is its scope? ===

The Council's primary responsibility is to act as technical watchdog for the intellectual content of the TEI Guidelines. That is to say: it has the final say in just about every aspect of the TEI encoding scheme -- what elements exist in it, what they are called, how they should be used.

=== How do I join the TEI Council mailing list? ===

We have had the practice on the Council so far that elected members get added immediately to the list (and to the telecon, if there is one), with every right to participate, while outgoing members stay on until the end of their term. To join or discuss any problems using the list contact the [mailto:tei-council-owner@lists.tei-c.org TEI Council mailing list owner], currently this is Kevin Hawkins (North Texas) and Nick Homenda (Indiana). There is also a joint Board/Council mailing list to which you should be added as well.

=== Why are some people on the Council email list or attending Council meetings even though they are not on the list of elected members? ===

In addition to the members of the Council, the chair of the TEI Technical Council may invite others not elected to the Council to meetings (e.g. to speak to a particular issue). Historically the Council often invited a representative of the Board to the Council mailing list and meetings. The TEI-C Webmaster (currently Kevin Hawkins) and Assistant Webmaster (Nick Homenda) are also on the mailing lists.

=== What are the various job roles on the TEI Council? ===

==== TEI Technical Council Member ====
A TEI Technical Council Member is expected to participate in all aspects of Council work. This means that they should learn how the TEI infrastructure is organised and [http://www.tei-c.org/Activities/Council/Working/tcw20.xml how to edit the TEI Guidelines], asking on the Council list any questions they might have. They will be expected to come to face-to-face ("f2f") meetings (often two per year) and participate in a couple other teleconferences per year. They will be assigned (or take) feature requests/bugs on [https://github.com/TEIC the TEI Consortium's GitHub site], for which they will be in charge of encouraging discussion, reporting on the issue to Council, and eventually implementing (or ensuring implementation) of the resulting decision. A TEI Technical Council Member is expected to participate in the maintenance and development of the TEI Guidelines and related outputs. Some elected TEI Council members focus more on particular aspects of the infrastructure or stylesheets as part of the contribution to the Council. Council members should always act to represent what they believe are the opinions and best interest of the community that has elected them.

==== TEI Technical Council Chair ====
The TEI Technical Council Chair's role is to administrate and facilitate the work of the TEI Technical Council. If all of the Council are the elected servants of the community, then the Council Chair is the servant of the servants of the TEI (''Servus servorum TEI''). The duties of the Technical Council Chair include (in no particular order):
* ensuring the delivery and maintenance of the Guidelines
* arranging for Council members to actively participate in Council activities
* arranging and chairing the face-to-face meetings (in conjunction with the local organiser)
* arranging and chairing the teleconferences
* creating agendas for those meetings, and ensuring minutes are written and posted of them
* assigning tickets in [http://github.com/TEIC/ the TEIC Github organization]
* acting as SIG coordinator
* liaising for and reporting on Council activities at all Board meetings
* reflecting Council wishes in Board discussions
* acting as a public point of contact and responding to technical enquiries (messages to council@tei-c.org are forwarded to the Council Chair)
* announcing new releases of the Guidelines on the TEI-L mailing list
* ensuring the smooth running of the TEI Technical Council

The TEI Technical Council Chair is also a member of the Council, so has all the duties and obligations of being a council member as well.

==== Release Technician ====
The TEI Guidelines release process (see [http://www.tei-c.org/Activities/Council/Working/tcw22.xml tcw22: Building a TEI Release]) involves a single individual responsible for 'pushing the button' and completing the steps required to make a TEI Guidelines release live. This is not a standing position; instead, the responsibility rotates for every release in order to demystify the release process and spread the expertise beyond Oxford staff. Although we have documented the work in quite a detailed manner, it is a non-trivial process and involves a fair degree of work. A release technician is usually required to set aside a whole day for the release process since history teaches us that often the entire process needs to be re-run to correct last-minute errors.

==== TEI-C Webmaster and Assistant Webmaster ====

The TEI-C Webmaster and Assistant Webmaster are not officially part of the Council but may be added to the mailing lists at the discretion of the Council Chair. They are responsible for the smooth running of the TEI-C Website.

=== How is the TEI Technical Council Chair elected? ===

The [http://www.tei-c.org/About/bylaws.xml#body.1_div.3_div.3 Bylaws of the TEI-C] say that:
<blockquote>
The Chair of the Technical Council shall be elected by the voting Members of the TEI-C Technical Council from its membership and shall serve as the chief technical officer of the Consortium. If no Technical Council Member is able or willing to assume the chair, the Technical Council may request the Board of Directors to second one of its elected members to the role, or it may nominate a non-elected individual.
</blockquote>
This leaves it intentionally vague as to the precise process the TEI Technical Council will follow. For now there is vague consensus that they will do something like the following. Note that timeframes below are not intended to be rigid or precise, but rather to be suggestive.
# The new Technical Council Members will be added to the tei-council (and tei-board-council) mailing lists shortly after the members' meeting. Up until around the last last Friday in November those who are Council members for next year will consider whether they want to run to be Chair of the TEI Technical Council. The current Chair will facilitate this process by answering any questions about the post. Before that date those intending to stand should send a statement of some sort to the Council mailing list detailing why they think the council members should vote for them.
# On or around the first weekday of December if only one person is running then the Chair will announce this to the tei-council mailing list as an acclamation (and after a short period for objections, to the Board and TEI-L). If multiple people are running, then the Council Chair will appoint a "returning officer" who is not a member of the incoming Council (i.e., not a voter and thus at least a somewhat disinterested party). The returning officer will set up an electronic voting system with the names of the candidates. This should be a private election with no one able to determine who has voted for whom. E.g. if using opavote.org this should have the following settings:
## Results only shown at end
## Method: "Plurality/FPTP/SNTV" for 2 candidates, "Instant Runoff Voting" for 3 or more
## a single winner
## Ballot type: "choose one" for 2 candidates, "ranked enhanced" for 3 or more
## candidate order shuffled
# The returning officer should ensure the election runs for at least 4 days, preferably in early December, after announcing it on the tei-council mailing list (and distributing ballots depending on the system).
# The results will be announced publicly on the tei-council mailing list, and Council members given a brief chance to raise any objections with the election before the current Chair informs the Board and announces it more publicly on TEI-L.
# The new Chair assumes the role on 1 January. The current chair steps down on 31 December. The outgoing and incoming chairs should co-ordinate activities between the election and 1 January so as to ensure a smooth transition. (Remembering that the current Chair might be departing off council at the end of that year.) These dates and timescales can of course shift and are not meant to be set in stone.

== Terminology ==

=== What was the War on Free-text-bearing Attribute Values? ===

The War on Free-text-bearing Attribute Values, also known as the War on Free-text-bearing Attributes and the War on Attributes for short, happened because some have felt that if attribute values don't have a datatype, they are more prone to abuse than if they did. So there has been an effort to give datatypes to as many attributes as possible. Some discussion of this with respect to @rend is available here: http://blogs.oucs.ox.ac.uk/jamesc/2011/12/01/rend-and-the-war-on-text-bearing-attributes/

=== What is the "Birnbaum doctrine"? ===

As expressed in [http://www.tei-c.org/Activities/Council/Working/tcw09.xml TCW09: Backward Compatibility and the Maintenance of the Text Encoding Initiative Guidelines], we should avoid breaking backward compatibility and only do so after serious consideration. It does not mean that we cannot break backwards compatibility, just that we've agreed a set of steps to take when we do so. Our deprecation policy supersedes some of this.

=== In what ways will Council break backwards compatibility? ===

For an egregious error, we might actually change a content model immediately. More often, we will survey the community on TEI-L before doing so, and we might [[Practices no longer recommended or now deprecated|deprecate]].

=== What is the "Durand Conundrum"? ===

The "Durand Conundrum" was suggested by David G. Durand concerning the TEI's decision to use the [[ODD | TEI ODD]] meta-schema language rather than just one of the existing schema languages. Given that we decided to use our own language, why use RelaxNG as part of that language for describing content models? Generally, the consensus is that [[ODD | TEI ODD]] gives us greater power and flexibility than any individual schema language can do in that we can model things that those schema languages are currently unable to cope with. TEI ODD gives the ability for a single document to produce both documentation and schema since these are inherently interlinked. It also keeps the TEI honest, in requiring it to use its own system to document schemas. [[ODD | TEI ODD]] does currently have some problems, a few of which are detailed at [[ODD-dev]] and successive revisions of TEI ODD are intended to solve some of these. Increasingly [[ODD#Future_plans:_.22Pure_ODD.22|the work on Pure ODD elements for content models and datatypes]] has cut the gordian knot of this problem.

=== What does "no magic" mean? ===

'Magic' in the sense sometimes used in Council discussion refers to pre-existing or special knowledge required to process something. For example, it was only by 'magic' that a TEI ODD processor would know to add attributes from the att.global attribute class to elements until this was changed to make all element specifications have to explicitly claim membership in this class if they wanted the global attributes. Knowing to add them was 'magic', and in general it is better if any requirements or understood knowledge is explicitly documented. While some 'magic' of understood conventions or processing will always remain in complex technical systems, the Council strives to at very least enable the possibility of documenting the underlying rules when it discovers them. James Cummings has been a fervent proponent of the removal of any understood 'magic' rules from the TEI.

=== What is a "magic token"? ===

This is an value, usually an attribute value, such as that of @key or @rend, which does not follow a standard outside vocabulary but instead is understood in some undocumented way and often used for local processing. It should usually be explained in the teiHeader if possible. Having any processing rely on undocumented magic tokens is generally considered a bad idea. See also [http://en.wikipedia.org/wiki/Magic_cookie Magic Cookie].

=== What is a non-deterministic content model? ===

If you have a content model for <a>:

<pre>
b*, c?, b*
</pre>

and you have a document with:

<pre>
<a>

</a>
</pre>

then a parser can't tell whether the matches the first b* or the second b* in the content model. Thus, the content model itself is called “non-deterministic”. DTDs and W3C XML Schemas reject non-deterministic content models. Thus, if we were to create one in the TEI, validation with DTD and XSD would fail due to errors ''in the schema'', regardless of whether the instance document has an occurence that is non-deterministic or not.

=== What are Janus elements? ===

These are pairs of elements that are in a sense two sides of the same coin, such as orig and reg, corr and sic, abbr and expan.

=== What does it mean to say that elements tessellate? ===

This means that all textual content is included in exactly one instance of an element. For example, once you start using divs (numbered or unnumbered), all text thereafter must be inside of one of the divs: you can't start using p elements that are not wrapped in a div.

In the Guidelines this is sometimes referred to as end-to-end segmentation.

== Meetings ==

=== Where are the minutes of previous meetings? ===

Minutes are [http://www.tei-c.org/Activities/Council/Meetings/index.xml archived on the TEI website]. Interim states of minutes may at times live in this wiki, Google Docs, or elsewhere.

=== How are the Council meetings held? ===

The Council usually makes use of Google Meet/Hangouts for their meetings. The meeting link will be in the agenda and/or sent out on the Council list before the meeting.

=== What funding is available for Council Activities? And how do I get reimbursed? ===

The TEI funds the participation of the council members in the meetings. Though I don't know of anyone claiming back telephone conferencing costs, I suppose that is possible as well, in most cases the council members' institutions probably swallow that.

If the council has a meeting, then the council members' travel, hotel, etc. will be reimbursed with proper receipts. The TEI reimburses all reasonable expenses in keeping with standard practice at most universities and granting agencies. We cover meals, travel, lodging, and other common daily travel expenses. Airfare should be economy class and direct return, unless otherwise arranged with the Treasurer prior to your trip. (See [http://www.tei-c.org/Board/procedures.xml#body.1_div.8 draft reimbursement policies and procedures].) If you have questions about reimbursement procedures, including what is reimbursable, please email John Unsworth, the TEI treasurer, at john.m.unsworth AT gmail.com.

Use the TEI Travel expense form available here: https://www.tei-c.org/wp-content/uploads/2017/10/TEI_travel_form.pdf '''Expense forms should be submitted within 10 days of the end of the meeting.'''

Council members are not funded to attend the TEI Members' Meeting, however, there has been discussion concerning whether the council should also officially meet here as well.

== How we get work done ==

=== I have something to say about a GitHub Feature Request or Bug: Should I comment on the issue or the TEI Council mailing list? ===

There is no hard-and-fast policy on this. The mailing list is a better place for ongoing discussions where people are arguing back and forth during decision making. The GitHub tracker is the appropriate place to record opinions, positions, and decisions for posterity, especially if such would help a) whoever is implementing the decisions recorded in the ticket, b) anyone revisiting this decision later to retrace the thinking. The [http://lists.tei-c.org/pipermail/tei-council/ TEI Council mailing list archives] are public, so if substantial discussion has taken place there (or indeed on TEI-L), this can also be linked to from the ticket.

=== When is discussion on an element or topic "closed" and how do I know? ===

Any topic can be revisited at any point, even in the published guidelines, through posting a feature request on GitHub. Council-specific issues should be raised on the council mailing list, after having reviewed any previous discussion on the topic in the [http://lists.tei-c.org/pipermail/tei-council/ tei-council mailing list archives].

=== How can I find out about every time a ticket is created or commented on? ===

Each repository has a "watch" control, which is to be found on the top right or the repo's GitHub page, below the navigation bar. This control lets you manage notifications in various ways.

=== How are tickets assigned in GitHub? ===
All members of Council are made part of the Council Team on the GitHub TEIC Organisation and meant to take an active role in the development and maintenance of the TEI Guidelines. This means that they have write access to the TEI Guidelines Github Repository, and tickets can be assigned to them in the ticket trackers. They can also update and modify tickets. This means that Council members are free to 'take' tickets which they wish to oversee. Other Council members can also 'give' tickets to each other if they think someone particularly suited to overseeing a particular ticket. (However, usually they should have the Council member's permission to do so.) On a regular basis the Council Chair will assign tickets to Council members, if a ticket gets assigned to them that they don't want to do they should tell the Chair and/or ask other Council members to swap.

=== What do the issue labels mean? ===

* 'Status: Blocked' means that the issue cannot be progressed because it requires either that another issue be completed first or that more information is needed from the reporter or a third party.

* 'Status: Needs Discussion' means that the issue has not been talked about enough yet to resolve it. New issues nearly always go into this status first. When Council has face-to-face meetings, these are usually the issues we target first.

* 'Status: Go' means that the ticket has been discussed, there is general consensus on what the correct thing to do is, and it has been assigned for someone to ensure its implementation.

* Other labels should be self-explanatory, and are sometimes created as needed to group tickets for various purposes.

=== How does a TEI release happen? ===

The process of making a release is documented at http://www.tei-c.org/Activities/Council/Working/tcw22.xml

== Working in GitHub ==

=== How do I edit the TEI Guidelines? ===

Editing the TEI Guidelines is a complex process and the Council has produced a document http://www.tei-c.org/Activities/Council/Working/tcw20.xml covering the logical and physical layout of the Guidelines, stylistic notes, how to make a change to the Guidelines (it requires [[TEI-Council-FAQ#How_do_I_use_GitHub.3F|using subversion]], building a release, and a reference section of useful information. If any information you need isn't in this document, ask on the Council list and get someone to update it!

=== How can I find out about every time a change is made in the TEI GitHub repository? ===
# Go to https://github.com/TEIC/
# Make sure you are logged in and
# go into each repository you are interested in and 'watch' them.

=== How do I use GitHub? ===
The TEI stores its working files in repositories in the [https://github.com/TEIC TEIC GitHub Organization]. See the [http://www.tei-c.org/guidelines/p5/using-the-tei-github-repository/ instructions]. Write access is reserved for those who are on the TEI Council or TEI Contributors teams. Any Council member should be able to add you to the Council team.

=== What should I put in a GitHub commit message? ===

It is beneficial to all those looking at the TEI GitHub repository if commit messages are clear and detailed. This is especially true when trying to revert changes made by yourself or others to solve problems. A good commit message will include:
* a subject line less than 72 characters long (which may be the whole message if no more is needed)
* an explanation to a useful level of detail about what you did
* a mention of why this is being done
* the GitHub issue numbers (or urls) that relate to the change if applicable
* an explanation of whether this change is completing the work described or one step towards doing so.

== TEI website ==

=== I want to add a document to add meeting minutes, reports, or working papers to the TEI-C website. How do I do that? ===

The TEI webmasters -- currently Kevin Hawkins and Nick Homenda -- have access to the CMS behind the TEI website. The site uses a stylesheet to render TEI Lite documents in XHTML, though the CMS can also deliver non-TEI documents. However, for long-term preservation and consistency, use of TEI Lite is encouraged.

You can author a document from scratch or take an existing document as a starting point. To get the XML source of an existing document, simply click "XML View" in the footer of a page on the TEI-C website and choose "save as" in your browser.

The TEI has a longstanding naming convention for files that consists of:

# a short alphabetical abbreviation for a committee (such as "tc" for "Technical Council")
# a one-letter abbreviation for minutes ("m"), reports ("r"), or working papers ("w")
# a two-digit number for the document with a committee series, numbered sequentially (e.g., "tcw01" is the first working paper from the Technical Council, "tcm05" is the fifth minutes from the Technical Council, etc.)

There is no registry of documents, so when creating a new one, you simply name the file appropriately.

Send the file to a webmaster for putting online. If you are hesitant to have the page go live until you have previewed it, you can ask the webmaster to send you a derived HTML version using the stylesheets without publishing that document.

=== How do I get access to the Google Analytics Data for www.tei-c.org? ===

Email the TEI-C webmaster: web@tei-c.org.

== Miscellaneous ==

=== Why do some elements have @type and others do not? ===

The TEI has avoided adding @type globally to elements because its availability is thought to invite tag or attribute abuse. In order for a request to add @type to an element to be considered for prolonged discussion and argument the TEI Technical Council has a standing principle that an element should be both repeatable and have obvious different classifications that apply to it. If such a request is approved then the preferred method is to make the element a member of the att.typed class (because if you can have @type, you can also have sub-types and thus need @subtype). If a closed or suggested value list, or different description is needed, this should then be provided as a local modification to the attributes inherited from att.typed.

== I have a question! ==

Then add it just above this one or email someone on the council or the council list reminding them of the existence of this wiki page when you ask your question.

[[Category:Council]]

TEI-Council-FAQ

2019-10-08T14:43:33Z

Hcayless: /* What is a non-deterministic content model? */

So you have some questions about how the [[Council|TEI Technical Council]] works? This page has been set up to answer questions that new council members (or other curious parties) may have.

== Overview ==

=== How does the Council do its work? ===

By every means possible. These include regular telephone conferences, endless streams of email, widely circulated discussion documents, private caucussing, public debate in other contexts such as TEI-L, and private gossip. Formally speaking, the Council meets face to face once a year (at least), and many more times than that virtually.

=== And what work does it do? ===

You should probably review the recent official work of the Council by reading the last few sets of minutes: http://www.tei-c.org/Council/ has an index page which links to them all (when we remember to update it). The minutes record topics discussed and responsibilities allocated at the Council level. Of course many Council members are also active in subgroups (formal or informal) of the Council or SIGs, which may be documented elsewhere as well.

Generally, things in Council work like this:

# A bug report or feature request is reported by anyone at [https://github.com/TEIC/ GitHub] for the [https://github.com/TEIC/TEI/issues Guidelines] or [https://github.com/TEIC/Stylesheets/issues Stylesheets].
# Sometimes others notice the ticket and comment on it.
# Sometimes a Council member may make an executive decision on the ticket. If it's a corrigible error or bug, we can just fix it in the appropriate ODD file(s) (also in GitHub). If it is not a real issue, sometimes the ticket will just be closed. If you do not have developer access on GitHub you'll to ask to be added to the Council team there. Otherwise, it's discussed either by email on the Council mailing list or at a Council meeting (conference call or in-person meeting). Comments are recorded in the ticket reflecting the decision reached, and changes are made in GitHub by a member of the Council sometime thereafter.
# The change shows up on tei-c.org after the next TEI "release", which happens about two or three times a year.

However, Council does sometimes consider lengthy proposals circulated to Council outside of GitHub and vote on them as packages, with the changes grouped together in a sensible way so they can be considered in smaller packages, or with the changes listed individually.

=== And what is its scope? ===

The Council's primary responsibility is to act as technical watchdog for the intellectual content of the TEI Guidelines. That is to say: it has the final say in just about every aspect of the TEI encoding scheme -- what elements exist in it, what they are called, how they should be used.

=== How do I join the TEI Council mailing list? ===

We have had the practice on the Council so far that elected members get added immediately to the list (and to the telecon, if there is one), with every right to participate, while outgoing members stay on until the end of their term. To join or discuss any problems using the list contact the [mailto:tei-council-owner@lists.tei-c.org TEI Council mailing list owner], currently this is Kevin Hawkins (North Texas) and Nick Homenda (Indiana). There is also a joint Board/Council mailing list to which you should be added as well.

=== Why are some people on the Council email list or attending Council meetings even though they are not on the list of elected members? ===

In addition to the members of the Council, the chair of the TEI Technical Council may invite others not elected to the Council to meetings (e.g. to speak to a particular issue). Historically the Council often invited a representative of the Board to the Council mailing list and meetings. The TEI-C Webmaster (currently Kevin Hawkins) and Assistant Webmaster (Nick Homenda) are also on the mailing lists.

=== What are the various job roles on the TEI Council? ===

==== TEI Technical Council Member ====
A TEI Technical Council Member is expected to participate in all aspects of Council work. This means that they should learn how the TEI infrastructure is organised and [http://www.tei-c.org/Activities/Council/Working/tcw20.xml how to edit the TEI Guidelines], asking on the Council list any questions they might have. They will be expected to come to face-to-face ("f2f") meetings (often two per year) and participate in a couple other teleconferences per year. They will be assigned (or take) feature requests/bugs on [https://github.com/TEIC the TEI Consortium's GitHub site], for which they will be in charge of encouraging discussion, reporting on the issue to Council, and eventually implementing (or ensuring implementation) of the resulting decision. A TEI Technical Council Member is expected to participate in the maintenance and development of the TEI Guidelines and related outputs. Some elected TEI Council members focus more on particular aspects of the infrastructure or stylesheets as part of the contribution to the Council. Council members should always act to represent what they believe are the opinions and best interest of the community that has elected them.

==== TEI Technical Council Chair ====
The TEI Technical Council Chair's role is to administrate and facilitate the work of the TEI Technical Council. If all of the Council are the elected servants of the community, then the Council Chair is the servant of the servants of the TEI (''Servus servorum TEI''). The duties of the Technical Council Chair include (in no particular order):
* ensuring the delivery and maintenance of the Guidelines
* arranging for Council members to actively participate in Council activities
* arranging and chairing the face-to-face meetings (in conjunction with the local organiser)
* arranging and chairing the teleconferences
* creating agendas for those meetings, and ensuring minutes are written and posted of them
* assigning tickets in [http://github.com/TEIC/ the TEIC Github organization]
* acting as SIG coordinator
* liaising for and reporting on Council activities at all Board meetings
* reflecting Council wishes in Board discussions
* acting as a public point of contact and responding to technical enquiries (messages to council@tei-c.org are forwarded to the Council Chair)
* announcing new releases of the Guidelines on the TEI-L mailing list
* ensuring the smooth running of the TEI Technical Council

The TEI Technical Council Chair is also a member of the Council, so has all the duties and obligations of being a council member as well.

==== Release Technician ====
The TEI Guidelines release process (see [http://www.tei-c.org/Activities/Council/Working/tcw22.xml tcw22: Building a TEI Release]) involves a single individual responsible for 'pushing the button' and completing the steps required to make a TEI Guidelines release live. This is not a standing position; instead, the responsibility rotates for every release in order to demystify the release process and spread the expertise beyond Oxford staff. Although we have documented the work in quite a detailed manner, it is a non-trivial process and involves a fair degree of work. A release technician is usually required to set aside a whole day for the release process since history teaches us that often the entire process needs to be re-run to correct last-minute errors.

==== TEI-C Webmaster and Assistant Webmaster ====

The TEI-C Webmaster and Assistant Webmaster are not officially part of the Council but may be added to the mailing lists at the discretion of the Council Chair. They are responsible for the smooth running of the TEI-C Website.

=== How is the TEI Technical Council Chair elected? ===

The [http://www.tei-c.org/About/bylaws.xml#body.1_div.3_div.3 Bylaws of the TEI-C] say that:
<blockquote>
The Chair of the Technical Council shall be elected by the voting Members of the TEI-C Technical Council from its membership and shall serve as the chief technical officer of the Consortium. If no Technical Council Member is able or willing to assume the chair, the Technical Council may request the Board of Directors to second one of its elected members to the role, or it may nominate a non-elected individual.
</blockquote>
This leaves it intentionally vague as to the precise process the TEI Technical Council will follow. For now there is vague consensus that they will do something like the following. Note that timeframes below are not intended to be rigid or precise, but rather to be suggestive.
# The new Technical Council Members will be added to the tei-council (and tei-board-council) mailing lists shortly after the members' meeting. Up until around the last last Friday in November those who are Council members for next year will consider whether they want to run to be Chair of the TEI Technical Council. The current Chair will facilitate this process by answering any questions about the post. Before that date those intending to stand should send a statement of some sort to the Council mailing list detailing why they think the council members should vote for them.
# On or around the first weekday of December if only one person is running then the Chair will announce this to the tei-council mailing list as an acclamation (and after a short period for objections, to the Board and TEI-L). If multiple people are running, then the Council Chair will appoint a "returning officer" who is not a member of the incoming Council (i.e., not a voter and thus at least a somewhat disinterested party). The returning officer will set up an electronic voting system with the names of the candidates. This should be a private election with no one able to determine who has voted for whom. E.g. if using opavote.org this should have the following settings:
## Results only shown at end
## Method: "Plurality/FPTP/SNTV" for 2 candidates, "Instant Runoff Voting" for 3 or more
## a single winner
## Ballot type: "choose one" for 2 candidates, "ranked enhanced" for 3 or more
## candidate order shuffled
# The returning officer should ensure the election runs for at least 4 days, preferably in early December, after announcing it on the tei-council mailing list (and distributing ballots depending on the system).
# The results will be announced publicly on the tei-council mailing list, and Council members given a brief chance to raise any objections with the election before the current Chair informs the Board and announces it more publicly on TEI-L.
# The new Chair assumes the role on 1 January. The current chair steps down on 31 December. The outgoing and incoming chairs should co-ordinate activities between the election and 1 January so as to ensure a smooth transition. (Remembering that the current Chair might be departing off council at the end of that year.) These dates and timescales can of course shift and are not meant to be set in stone.

== Terminology ==

=== What was the War on Free-text-bearing Attribute Values? ===

The War on Free-text-bearing Attribute Values, also known as the War on Free-text-bearing Attributes and the War on Attributes for short, happened because some have felt that if attribute values don't have a datatype, they are more prone to abuse than if they did. So there has been an effort to give datatypes to as many attributes as possible. Some discussion of this with respect to @rend is available here: http://blogs.oucs.ox.ac.uk/jamesc/2011/12/01/rend-and-the-war-on-text-bearing-attributes/

=== What is the "Birnbaum doctrine"? ===

As expressed in [http://www.tei-c.org/Activities/Council/Working/tcw09.xml TCW09: Backward Compatibility and the Maintenance of the Text Encoding Initiative Guidelines], we should avoid breaking backward compatibility and only do so after serious consideration. It does not mean that we cannot break backwards compatibility, just that we've agreed a set of steps to take when we do so. Our deprecation policy supersedes some of this.

=== In what ways will Council break backwards compatibility? ===

For an egregious error, we might actually change a content model immediately. More often, we will survey the community on TEI-L before doing so, and we might [[Practices no longer recommended or now deprecated|deprecate]].

=== What is the "Durand Conundrum"? ===

The "Durand Conundrum" was suggested by David G. Durand concerning the TEI's decision to use the [[ODD | TEI ODD]] meta-schema language rather than just one of the existing schema languages. Given that we decided to use our own language, why use RelaxNG as part of that language for describing content models? Generally, the consensus is that [[ODD | TEI ODD]] gives us greater power and flexibility than any individual schema language can do in that we can model things that those schema languages are currently unable to cope with. TEI ODD gives the ability for a single document to produce both documentation and schema since these are inherently interlinked. It also keeps the TEI honest, in requiring it to use its own system to document schemas. [[ODD | TEI ODD]] does currently have some problems, a few of which are detailed at [[ODD-dev]] and successive revisions of TEI ODD are intended to solve some of these. Increasingly [[ODD#Future_plans:_.22Pure_ODD.22|the work on Pure ODD elements for content models and datatypes]] has cut the gordian knot of this problem.

=== What does "no magic" mean? ===

'Magic' in the sense sometimes used in Council discussion refers to pre-existing or special knowledge required to process something. For example, it was only by 'magic' that a TEI ODD processor would know to add attributes from the att.global attribute class to elements until this was changed to make all element specifications have to explicitly claim membership in this class if they wanted the global attributes. Knowing to add them was 'magic', and in general it is better if any requirements or understood knowledge is explicitly documented. While some 'magic' of understood conventions or processing will always remain in complex technical systems, the Council strives to at very least enable the possibility of documenting the underlying rules when it discovers them. James Cummings has been a fervent proponent of the removal of any understood 'magic' rules from the TEI.

=== What is a "magic token"? ===

This is an value, usually an attribute value, such as that of @key or @rend, which does not follow a standard outside vocabulary but instead is understood in some undocumented way and often used for local processing. It should usually be explained in the teiHeader if possible. Having any processing rely on undocumented magic tokens is generally considered a bad idea. See also [http://en.wikipedia.org/wiki/Magic_cookie Magic Cookie].

=== What is a non-deterministic content model? ===

If you have a content model for <a>:

<pre>
b*, c?, b*
</pre>

and you have a document with:

<pre>
<a>

</a>
</pre>

then a parser can't tell whether the matches the first b* or the second b* in the content model. Thus, the content model itself is called “non-deterministic”. DTDs and W3C XML Schemas reject non-deterministic content models. Thus, if we were to create one in the TEI, validation with DTD and XSD would fail due to errors ''in the schema'', regardless of whether the instance document has an occurence that is non-deterministic or not.

=== What are Janus elements? ===

These are pairs of elements that are in a sense two sides of the same coin, such as orig and reg, corr and sic, abbr and expan.

=== What does it mean to say that elements tessellate? ===

This means that all textual content is included in exactly one instance of an element. For example, once you start using divs (numbered or unnumbered), all text thereafter must be inside of one of the divs: you can't start using p elements that are not wrapped in a div.

In the Guidelines this is sometimes referred to as end-to-end segmentation.

== Meetings ==

=== Where are the minutes of previous meetings? ===

Minutes are [http://www.tei-c.org/Activities/Council/Meetings/index.xml archived on the TEI website]. Interim states of minutes may at times live in this wiki, Google Docs, or elsewhere.

=== How are the Council meetings held? ===

The Council usually makes use of Google Meet/Hangouts for their meetings. The meeting link will be in the agenda and/or sent out on the Council list before the meeting.

=== What funding is available for Council Activities? And how do I get reimbursed? ===

The TEI funds the participation of the council members in the meetings. Though I don't know of anyone claiming back telephone conferencing costs, I suppose that is possible as well, in most cases the council members' institutions probably swallow that.

If the council has a meeting, then the council members' travel, hotel, etc. will be reimbursed with proper receipts. The TEI reimburses all reasonable expenses in keeping with standard practice at most universities and granting agencies. We cover meals, travel, lodging, and other common daily travel expenses. Airfare should be economy class and direct return, unless otherwise arranged with the Treasurer prior to your trip. (See [http://www.tei-c.org/Board/procedures.xml#body.1_div.8 draft reimbursement policies and procedures].) If you have questions about reimbursement procedures, including what is reimbursable, please email John Unsworth, the TEI treasurer, at john.m.unsworth AT gmail.com.

Use the TEI Travel expense form available here: https://www.tei-c.org/wp-content/uploads/2017/10/TEI_travel_form.pdf '''Expense forms should be submitted within 10 days of the end of the meeting.'''

Council members are not funded to attend the TEI Members' Meeting, however, there has been discussion concerning whether the council should also officially meet here as well.

== How we get work done ==

=== I have something to say about a GitHub Feature Request or Bug: Should I comment on the issue or the TEI Council mailing list? ===

There is no hard-and-fast policy on this. The mailing list is a better place for ongoing discussions where people are arguing back and forth during decision making. The GitHub tracker is the appropriate place to record opinions, positions, and decisions for posterity, especially if such would help a) whoever is implementing the decisions recorded in the ticket, b) anyone revisiting this decision later to retrace the thinking. The [http://lists.tei-c.org/pipermail/tei-council/ TEI Council mailing list archives] are public, so if substantial discussion has taken place there (or indeed on TEI-L), this can also be linked to from the ticket.

=== When is discussion on an element or topic "closed" and how do I know? ===

Any topic can be revisited at any point, even in the published guidelines, through posting a feature request on GitHub. Council-specific issues should be raised on the council mailing list, after having reviewed any previous discussion on the topic in the [http://lists.tei-c.org/pipermail/tei-council/ tei-council mailing list archives].

=== How can I find out about every time a ticket is created or commented on? ===

Each repository has a "watch" control, which is to be found on the top right or the repo's GitHub page, below the navigation bar. This control lets you manage notifications in various ways.

=== How are tickets assigned in GitHub? ===
All members of Council are made part of the Council Team on the GitHub TEIC Organisation and meant to take an active role in the development and maintenance of the TEI Guidelines. This means that they have write access to the TEI Guidelines Github Repository, and tickets can be assigned to them in the ticket trackers. They can also update and modify tickets. This means that Council members are free to 'take' tickets which they wish to oversee. Other Council members can also 'give' tickets to each other if they think someone particularly suited to overseeing a particular ticket. (However, usually they should have the Council member's permission to do so.) On a regular basis the Council Chair will assign tickets to Council members, if a ticket gets assigned to them that they don't want to do they should tell the Chair and/or ask other Council members to swap.

=== What do the issue labels mean? ===

* 'Status: Blocked' means that the issue cannot be progressed because it requires either that another issue be completed first or that more information is needed from the reporter or a third party.

* 'Status: Needs Discussion' means that the issue has not been talked about enough yet to resolve it. New issues nearly always go into this status first. When Council has face-to-face meetings, these are usually the issues we target first.

* 'Status: Go' means that the ticket has been discussed, there is general consensus on what the correct thing to do is, and it has been assigned for someone to ensure its implementation.

* Other labels should be self-explanatory, and are sometimes created as needed to group tickets for various purposes.

=== How does a TEI release happen? ===

The process of making a release is documented at http://www.tei-c.org/Activities/Council/Working/tcw22.xml

== Working in GitHub ==

=== How do I edit the TEI Guidelines? ===

Editing the TEI Guidelines is a complex process and the Council has produced a document http://www.tei-c.org/Activities/Council/Working/tcw20.xml covering the logical and physical layout of the Guidelines, stylistic notes, how to make a change to the Guidelines (it requires [[TEI-Council-FAQ#How_do_I_use_GitHub.3F|using subversion]], building a release, and a reference section of useful information. If any information you need isn't in this document, ask on the Council list and get someone to update it!

=== How can I find out about every time a change is made in the TEI GitHub repository? ===
# Go to https://github.com/TEIC/
# Make sure you are logged in and
# go into each repository you are interested in and 'watch' them.

=== How do I use GitHub? ===
The TEI stores its working files in repositories in the [https://github.com/TEIC TEIC GitHub Organization]. See the [http://www.tei-c.org/guidelines/p5/using-the-tei-github-repository/ instructions]. Write access is reserved for those who are on the TEI Council or TEI Contributors teams. Any Council member should be able to add you to the Council team.

=== What should I put in a GitHub commit message? ===

It is beneficial to all those looking at the TEI GitHub repository if commit messages are clear and detailed. This is especially true when trying to revert changes made by yourself or others to solve problems. A good commit message will include:
* a subject line less than 72 characters long (which may be the whole message if no more is needed)
* an explanation to a useful level of detail about what you did
* a mention of why this is being done
* the GitHub issue numbers (or urls) that relate to the change if applicable
* an explanation of whether this change is completing the work described or one step towards doing so.

== TEI website ==

=== I want to add a document to add meeting minutes, reports, or working papers to the TEI-C website. How do I do that? ===

The TEI webmasters -- currently Kevin Hawkins and Nick Homenda -- have access to the CMS behind the TEI website. The site uses a stylesheet to render TEI Lite documents in XHTML, though the CMS can also deliver non-TEI documents. However, for long-term preservation and consistency, use of TEI Lite is encouraged.

You can author a document from scratch or take an existing document as a starting point. To get the XML source of an existing document, simply click "XML View" in the footer of a page on the TEI-C website and choose "save as" in your browser.

The TEI has a longstanding naming convention for files that consists of:

# a short alphabetical abbreviation for a committee (such as "tc" for "Technical Council")
# a one-letter abbreviation for minutes ("m"), reports ("r"), or working papers ("w")
# a two-digit number for the document with a committee series, numbered sequentially (e.g., "tcw01" is the first working paper from the Technical Council, "tcm05" is the fifth minutes from the Technical Council, etc.)

There is no registry of documents, so when creating a new one, you simply name the file appropriately.

Send the file to a webmaster for putting online. If you are hesitant to have the page go live until you have previewed it, you can ask the webmaster to send you a derived HTML version using the stylesheets without publishing that document.

=== How do I get access to the Google Analytics Data for www.tei-c.org? ===

Email the TEI-C webmaster: web@tei-c.org.

== Miscellaneous ==

=== Why do some elements have @type and others do not? ===

The TEI has avoided adding @type globally to elements because its availability is thought to invite tag or attribute abuse. In order for a request to add @type to an element to be considered for prolonged discussion and argument the TEI Technical Council has a standing principle that an element should be both repeatable and have obvious different classifications that apply to it. If such a request is approved then the preferred method is to make the element a member of the att.typed class (because if you can have @type, you can also have sub-types and thus need @subtype). If a closed or suggested value list, or different description is needed, this should then be provided as a local modification to the attributes inherited from att.typed.

== I have a question! ==

Then add it just above this one or email someone on the council or the council list reminding them of the existence of this wiki page when you ask your question.

[[Category:Council]]

TEI-Council-FAQ

2019-10-08T14:40:23Z

Hcayless: /* How are the teleconferences held? */

So you have some questions about how the [[Council|TEI Technical Council]] works? This page has been set up to answer questions that new council members (or other curious parties) may have.

== Overview ==

=== How does the Council do its work? ===

By every means possible. These include regular telephone conferences, endless streams of email, widely circulated discussion documents, private caucussing, public debate in other contexts such as TEI-L, and private gossip. Formally speaking, the Council meets face to face once a year (at least), and many more times than that virtually.

=== And what work does it do? ===

You should probably review the recent official work of the Council by reading the last few sets of minutes: http://www.tei-c.org/Council/ has an index page which links to them all (when we remember to update it). The minutes record topics discussed and responsibilities allocated at the Council level. Of course many Council members are also active in subgroups (formal or informal) of the Council or SIGs, which may be documented elsewhere as well.

Generally, things in Council work like this:

# A bug report or feature request is reported by anyone at [https://github.com/TEIC/ GitHub] for the [https://github.com/TEIC/TEI/issues Guidelines] or [https://github.com/TEIC/Stylesheets/issues Stylesheets].
# Sometimes others notice the ticket and comment on it.
# Sometimes a Council member may make an executive decision on the ticket. If it's a corrigible error or bug, we can just fix it in the appropriate ODD file(s) (also in GitHub). If it is not a real issue, sometimes the ticket will just be closed. If you do not have developer access on GitHub you'll to ask to be added to the Council team there. Otherwise, it's discussed either by email on the Council mailing list or at a Council meeting (conference call or in-person meeting). Comments are recorded in the ticket reflecting the decision reached, and changes are made in GitHub by a member of the Council sometime thereafter.
# The change shows up on tei-c.org after the next TEI "release", which happens about two or three times a year.

However, Council does sometimes consider lengthy proposals circulated to Council outside of GitHub and vote on them as packages, with the changes grouped together in a sensible way so they can be considered in smaller packages, or with the changes listed individually.

=== And what is its scope? ===

The Council's primary responsibility is to act as technical watchdog for the intellectual content of the TEI Guidelines. That is to say: it has the final say in just about every aspect of the TEI encoding scheme -- what elements exist in it, what they are called, how they should be used.

=== How do I join the TEI Council mailing list? ===

We have had the practice on the Council so far that elected members get added immediately to the list (and to the telecon, if there is one), with every right to participate, while outgoing members stay on until the end of their term. To join or discuss any problems using the list contact the [mailto:tei-council-owner@lists.tei-c.org TEI Council mailing list owner], currently this is Kevin Hawkins (North Texas) and Nick Homenda (Indiana). There is also a joint Board/Council mailing list to which you should be added as well.

=== Why are some people on the Council email list or attending Council meetings even though they are not on the list of elected members? ===

In addition to the members of the Council, the chair of the TEI Technical Council may invite others not elected to the Council to meetings (e.g. to speak to a particular issue). Historically the Council often invited a representative of the Board to the Council mailing list and meetings. The TEI-C Webmaster (currently Kevin Hawkins) and Assistant Webmaster (Nick Homenda) are also on the mailing lists.

=== What are the various job roles on the TEI Council? ===

==== TEI Technical Council Member ====
A TEI Technical Council Member is expected to participate in all aspects of Council work. This means that they should learn how the TEI infrastructure is organised and [http://www.tei-c.org/Activities/Council/Working/tcw20.xml how to edit the TEI Guidelines], asking on the Council list any questions they might have. They will be expected to come to face-to-face ("f2f") meetings (often two per year) and participate in a couple other teleconferences per year. They will be assigned (or take) feature requests/bugs on [https://github.com/TEIC the TEI Consortium's GitHub site], for which they will be in charge of encouraging discussion, reporting on the issue to Council, and eventually implementing (or ensuring implementation) of the resulting decision. A TEI Technical Council Member is expected to participate in the maintenance and development of the TEI Guidelines and related outputs. Some elected TEI Council members focus more on particular aspects of the infrastructure or stylesheets as part of the contribution to the Council. Council members should always act to represent what they believe are the opinions and best interest of the community that has elected them.

==== TEI Technical Council Chair ====
The TEI Technical Council Chair's role is to administrate and facilitate the work of the TEI Technical Council. If all of the Council are the elected servants of the community, then the Council Chair is the servant of the servants of the TEI (''Servus servorum TEI''). The duties of the Technical Council Chair include (in no particular order):
* ensuring the delivery and maintenance of the Guidelines
* arranging for Council members to actively participate in Council activities
* arranging and chairing the face-to-face meetings (in conjunction with the local organiser)
* arranging and chairing the teleconferences
* creating agendas for those meetings, and ensuring minutes are written and posted of them
* assigning tickets in [http://github.com/TEIC/ the TEIC Github organization]
* acting as SIG coordinator
* liaising for and reporting on Council activities at all Board meetings
* reflecting Council wishes in Board discussions
* acting as a public point of contact and responding to technical enquiries (messages to council@tei-c.org are forwarded to the Council Chair)
* announcing new releases of the Guidelines on the TEI-L mailing list
* ensuring the smooth running of the TEI Technical Council

The TEI Technical Council Chair is also a member of the Council, so has all the duties and obligations of being a council member as well.

==== Release Technician ====
The TEI Guidelines release process (see [http://www.tei-c.org/Activities/Council/Working/tcw22.xml tcw22: Building a TEI Release]) involves a single individual responsible for 'pushing the button' and completing the steps required to make a TEI Guidelines release live. This is not a standing position; instead, the responsibility rotates for every release in order to demystify the release process and spread the expertise beyond Oxford staff. Although we have documented the work in quite a detailed manner, it is a non-trivial process and involves a fair degree of work. A release technician is usually required to set aside a whole day for the release process since history teaches us that often the entire process needs to be re-run to correct last-minute errors.

==== TEI-C Webmaster and Assistant Webmaster ====

The TEI-C Webmaster and Assistant Webmaster are not officially part of the Council but may be added to the mailing lists at the discretion of the Council Chair. They are responsible for the smooth running of the TEI-C Website.

=== How is the TEI Technical Council Chair elected? ===

The [http://www.tei-c.org/About/bylaws.xml#body.1_div.3_div.3 Bylaws of the TEI-C] say that:
<blockquote>
The Chair of the Technical Council shall be elected by the voting Members of the TEI-C Technical Council from its membership and shall serve as the chief technical officer of the Consortium. If no Technical Council Member is able or willing to assume the chair, the Technical Council may request the Board of Directors to second one of its elected members to the role, or it may nominate a non-elected individual.
</blockquote>
This leaves it intentionally vague as to the precise process the TEI Technical Council will follow. For now there is vague consensus that they will do something like the following. Note that timeframes below are not intended to be rigid or precise, but rather to be suggestive.
# The new Technical Council Members will be added to the tei-council (and tei-board-council) mailing lists shortly after the members' meeting. Up until around the last last Friday in November those who are Council members for next year will consider whether they want to run to be Chair of the TEI Technical Council. The current Chair will facilitate this process by answering any questions about the post. Before that date those intending to stand should send a statement of some sort to the Council mailing list detailing why they think the council members should vote for them.
# On or around the first weekday of December if only one person is running then the Chair will announce this to the tei-council mailing list as an acclamation (and after a short period for objections, to the Board and TEI-L). If multiple people are running, then the Council Chair will appoint a "returning officer" who is not a member of the incoming Council (i.e., not a voter and thus at least a somewhat disinterested party). The returning officer will set up an electronic voting system with the names of the candidates. This should be a private election with no one able to determine who has voted for whom. E.g. if using opavote.org this should have the following settings:
## Results only shown at end
## Method: "Plurality/FPTP/SNTV" for 2 candidates, "Instant Runoff Voting" for 3 or more
## a single winner
## Ballot type: "choose one" for 2 candidates, "ranked enhanced" for 3 or more
## candidate order shuffled
# The returning officer should ensure the election runs for at least 4 days, preferably in early December, after announcing it on the tei-council mailing list (and distributing ballots depending on the system).
# The results will be announced publicly on the tei-council mailing list, and Council members given a brief chance to raise any objections with the election before the current Chair informs the Board and announces it more publicly on TEI-L.
# The new Chair assumes the role on 1 January. The current chair steps down on 31 December. The outgoing and incoming chairs should co-ordinate activities between the election and 1 January so as to ensure a smooth transition. (Remembering that the current Chair might be departing off council at the end of that year.) These dates and timescales can of course shift and are not meant to be set in stone.

== Terminology ==

=== What was the War on Free-text-bearing Attribute Values? ===

The War on Free-text-bearing Attribute Values, also known as the War on Free-text-bearing Attributes and the War on Attributes for short, happened because some have felt that if attribute values don't have a datatype, they are more prone to abuse than if they did. So there has been an effort to give datatypes to as many attributes as possible. Some discussion of this with respect to @rend is available here: http://blogs.oucs.ox.ac.uk/jamesc/2011/12/01/rend-and-the-war-on-text-bearing-attributes/

=== What is the "Birnbaum doctrine"? ===

As expressed in [http://www.tei-c.org/Activities/Council/Working/tcw09.xml TCW09: Backward Compatibility and the Maintenance of the Text Encoding Initiative Guidelines], we should avoid breaking backward compatibility and only do so after serious consideration. It does not mean that we cannot break backwards compatibility, just that we've agreed a set of steps to take when we do so. Our deprecation policy supersedes some of this.

=== In what ways will Council break backwards compatibility? ===

For an egregious error, we might actually change a content model immediately. More often, we will survey the community on TEI-L before doing so, and we might [[Practices no longer recommended or now deprecated|deprecate]].

=== What is the "Durand Conundrum"? ===

The "Durand Conundrum" was suggested by David G. Durand concerning the TEI's decision to use the [[ODD | TEI ODD]] meta-schema language rather than just one of the existing schema languages. Given that we decided to use our own language, why use RelaxNG as part of that language for describing content models? Generally, the consensus is that [[ODD | TEI ODD]] gives us greater power and flexibility than any individual schema language can do in that we can model things that those schema languages are currently unable to cope with. TEI ODD gives the ability for a single document to produce both documentation and schema since these are inherently interlinked. It also keeps the TEI honest, in requiring it to use its own system to document schemas. [[ODD | TEI ODD]] does currently have some problems, a few of which are detailed at [[ODD-dev]] and successive revisions of TEI ODD are intended to solve some of these. Increasingly [[ODD#Future_plans:_.22Pure_ODD.22|the work on Pure ODD elements for content models and datatypes]] has cut the gordian knot of this problem.

=== What does "no magic" mean? ===

'Magic' in the sense sometimes used in Council discussion refers to pre-existing or special knowledge required to process something. For example, it was only by 'magic' that a TEI ODD processor would know to add attributes from the att.global attribute class to elements until this was changed to make all element specifications have to explicitly claim membership in this class if they wanted the global attributes. Knowing to add them was 'magic', and in general it is better if any requirements or understood knowledge is explicitly documented. While some 'magic' of understood conventions or processing will always remain in complex technical systems, the Council strives to at very least enable the possibility of documenting the underlying rules when it discovers them. James Cummings has been a fervent proponent of the removal of any understood 'magic' rules from the TEI.

=== What is a "magic token"? ===

This is an value, usually an attribute value, such as that of @key or @rend, which does not follow a standard outside vocabulary but instead is understood in some undocumented way and often used for local processing. It should usually be explained in the teiHeader if possible. Having any processing rely on undocumented magic tokens is generally considered a bad idea. See also [http://en.wikipedia.org/wiki/Magic_cookie Magic Cookie].

=== What is a non-deterministic content model? ===

If you have a content model for <tt><a></tt>:

<code>
b*, c?, b*
</code>

and you have a document with:

<pre>
<a>

</a>
</pre>

then a parser can't tell whether the <tt></tt> matches the first <tt>b*</tt> or the second <tt>b*</tt> in the content model. Thus, the content model itself is called “non-determinstic”. DTDs and W3C XML Schemas reject non-deterministic content models. Thus, if we were to create one in the TEI, validation with DTD and XSD would fail due to errors ''in the schema'', regardless of whether the instance document has an occurence that is non-deterministic or not.

=== What are Janus elements? ===

These are pairs of elements that are in a sense two sides of the same coin, such as orig and reg, corr and sic, abbr and expan.

=== What does it mean to say that elements tessellate? ===

This means that all textual content is included in exactly one instance of an element. For example, once you start using divs (numbered or unnumbered), all text thereafter must be inside of one of the divs: you can't start using p elements that are not wrapped in a div.

In the Guidelines this is sometimes referred to as end-to-end segmentation.

== Meetings ==

=== Where are the minutes of previous meetings? ===

Minutes are [http://www.tei-c.org/Activities/Council/Meetings/index.xml archived on the TEI website]. Interim states of minutes may at times live in this wiki, Google Docs, or elsewhere.

=== How are the Council meetings held? ===

The Council usually makes use of Google Meet/Hangouts for their meetings. The meeting link will be in the agenda and/or sent out on the Council list before the meeting.

=== What funding is available for Council Activities? And how do I get reimbursed? ===

The TEI funds the participation of the council members in the meetings. Though I don't know of anyone claiming back telephone conferencing costs, I suppose that is possible as well, in most cases the council members' institutions probably swallow that.

If the council has a meeting, then the council members' travel, hotel, etc. will be reimbursed with proper receipts. The TEI reimburses all reasonable expenses in keeping with standard practice at most universities and granting agencies. We cover meals, travel, lodging, and other common daily travel expenses. Airfare should be economy class and direct return, unless otherwise arranged with the Treasurer prior to your trip. (See [http://www.tei-c.org/Board/procedures.xml#body.1_div.8 draft reimbursement policies and procedures].) If you have questions about reimbursement procedures, including what is reimbursable, please email John Unsworth, the TEI treasurer, at john.m.unsworth AT gmail.com.

Use the TEI Travel expense form available here: https://www.tei-c.org/wp-content/uploads/2017/10/TEI_travel_form.pdf '''Expense forms should be submitted within 10 days of the end of the meeting.'''

Council members are not funded to attend the TEI Members' Meeting, however, there has been discussion concerning whether the council should also officially meet here as well.

== How we get work done ==

=== I have something to say about a GitHub Feature Request or Bug: Should I comment on the issue or the TEI Council mailing list? ===

There is no hard-and-fast policy on this. The mailing list is a better place for ongoing discussions where people are arguing back and forth during decision making. The GitHub tracker is the appropriate place to record opinions, positions, and decisions for posterity, especially if such would help a) whoever is implementing the decisions recorded in the ticket, b) anyone revisiting this decision later to retrace the thinking. The [http://lists.tei-c.org/pipermail/tei-council/ TEI Council mailing list archives] are public, so if substantial discussion has taken place there (or indeed on TEI-L), this can also be linked to from the ticket.

=== When is discussion on an element or topic "closed" and how do I know? ===

Any topic can be revisited at any point, even in the published guidelines, through posting a feature request on GitHub. Council-specific issues should be raised on the council mailing list, after having reviewed any previous discussion on the topic in the [http://lists.tei-c.org/pipermail/tei-council/ tei-council mailing list archives].

=== How can I find out about every time a ticket is created or commented on? ===

Each repository has a "watch" control, which is to be found on the top right or the repo's GitHub page, below the navigation bar. This control lets you manage notifications in various ways.

=== How are tickets assigned in GitHub? ===
All members of Council are made part of the Council Team on the GitHub TEIC Organisation and meant to take an active role in the development and maintenance of the TEI Guidelines. This means that they have write access to the TEI Guidelines Github Repository, and tickets can be assigned to them in the ticket trackers. They can also update and modify tickets. This means that Council members are free to 'take' tickets which they wish to oversee. Other Council members can also 'give' tickets to each other if they think someone particularly suited to overseeing a particular ticket. (However, usually they should have the Council member's permission to do so.) On a regular basis the Council Chair will assign tickets to Council members, if a ticket gets assigned to them that they don't want to do they should tell the Chair and/or ask other Council members to swap.

=== What do the issue labels mean? ===

* 'Status: Blocked' means that the issue cannot be progressed because it requires either that another issue be completed first or that more information is needed from the reporter or a third party.

* 'Status: Needs Discussion' means that the issue has not been talked about enough yet to resolve it. New issues nearly always go into this status first. When Council has face-to-face meetings, these are usually the issues we target first.

* 'Status: Go' means that the ticket has been discussed, there is general consensus on what the correct thing to do is, and it has been assigned for someone to ensure its implementation.

* Other labels should be self-explanatory, and are sometimes created as needed to group tickets for various purposes.

=== How does a TEI release happen? ===

The process of making a release is documented at http://www.tei-c.org/Activities/Council/Working/tcw22.xml

== Working in GitHub ==

=== How do I edit the TEI Guidelines? ===

Editing the TEI Guidelines is a complex process and the Council has produced a document http://www.tei-c.org/Activities/Council/Working/tcw20.xml covering the logical and physical layout of the Guidelines, stylistic notes, how to make a change to the Guidelines (it requires [[TEI-Council-FAQ#How_do_I_use_GitHub.3F|using subversion]], building a release, and a reference section of useful information. If any information you need isn't in this document, ask on the Council list and get someone to update it!

=== How can I find out about every time a change is made in the TEI GitHub repository? ===
# Go to https://github.com/TEIC/
# Make sure you are logged in and
# go into each repository you are interested in and 'watch' them.

=== How do I use GitHub? ===
The TEI stores its working files in repositories in the [https://github.com/TEIC TEIC GitHub Organization]. See the [http://www.tei-c.org/guidelines/p5/using-the-tei-github-repository/ instructions]. Write access is reserved for those who are on the TEI Council or TEI Contributors teams. Any Council member should be able to add you to the Council team.

=== What should I put in a GitHub commit message? ===

It is beneficial to all those looking at the TEI GitHub repository if commit messages are clear and detailed. This is especially true when trying to revert changes made by yourself or others to solve problems. A good commit message will include:
* a subject line less than 72 characters long (which may be the whole message if no more is needed)
* an explanation to a useful level of detail about what you did
* a mention of why this is being done
* the GitHub issue numbers (or urls) that relate to the change if applicable
* an explanation of whether this change is completing the work described or one step towards doing so.

== TEI website ==

=== I want to add a document to add meeting minutes, reports, or working papers to the TEI-C website. How do I do that? ===

The TEI webmasters -- currently Kevin Hawkins and Nick Homenda -- have access to the CMS behind the TEI website. The site uses a stylesheet to render TEI Lite documents in XHTML, though the CMS can also deliver non-TEI documents. However, for long-term preservation and consistency, use of TEI Lite is encouraged.

You can author a document from scratch or take an existing document as a starting point. To get the XML source of an existing document, simply click "XML View" in the footer of a page on the TEI-C website and choose "save as" in your browser.

The TEI has a longstanding naming convention for files that consists of:

# a short alphabetical abbreviation for a committee (such as "tc" for "Technical Council")
# a one-letter abbreviation for minutes ("m"), reports ("r"), or working papers ("w")
# a two-digit number for the document with a committee series, numbered sequentially (e.g., "tcw01" is the first working paper from the Technical Council, "tcm05" is the fifth minutes from the Technical Council, etc.)

There is no registry of documents, so when creating a new one, you simply name the file appropriately.

Send the file to a webmaster for putting online. If you are hesitant to have the page go live until you have previewed it, you can ask the webmaster to send you a derived HTML version using the stylesheets without publishing that document.

=== How do I get access to the Google Analytics Data for www.tei-c.org? ===

Email the TEI-C webmaster: web@tei-c.org.

== Miscellaneous ==

=== Why do some elements have @type and others do not? ===

The TEI has avoided adding @type globally to elements because its availability is thought to invite tag or attribute abuse. In order for a request to add @type to an element to be considered for prolonged discussion and argument the TEI Technical Council has a standing principle that an element should be both repeatable and have obvious different classifications that apply to it. If such a request is approved then the preferred method is to make the element a member of the att.typed class (because if you can have @type, you can also have sub-types and thus need @subtype). If a closed or suggested value list, or different description is needed, this should then be provided as a local modification to the attributes inherited from att.typed.

== I have a question! ==

Then add it just above this one or email someone on the council or the council list reminding them of the existence of this wiki page when you ask your question.

[[Category:Council]]

TEI-Council-FAQ

2019-10-08T14:26:04Z

Hcayless: /* What do the ticket labels mean? */

So you have some questions about how the [[Council|TEI Technical Council]] works? This page has been set up to answer questions that new council members (or other curious parties) may have.

== Overview ==

=== How does the Council do its work? ===

By every means possible. These include regular telephone conferences, endless streams of email, widely circulated discussion documents, private caucussing, public debate in other contexts such as TEI-L, and private gossip. Formally speaking, the Council meets face to face once a year (at least), and many more times than that virtually.

=== And what work does it do? ===

You should probably review the recent official work of the Council by reading the last few sets of minutes: http://www.tei-c.org/Council/ has an index page which links to them all (when we remember to update it). The minutes record topics discussed and responsibilities allocated at the Council level. Of course many Council members are also active in subgroups (formal or informal) of the Council or SIGs, which may be documented elsewhere as well.

Generally, things in Council work like this:

# A bug report or feature request is reported by anyone at [https://github.com/TEIC/ GitHub] for the [https://github.com/TEIC/TEI/issues Guidelines] or [https://github.com/TEIC/Stylesheets/issues Stylesheets].
# Sometimes others notice the ticket and comment on it.
# Sometimes a Council member may make an executive decision on the ticket. If it's a corrigible error or bug, we can just fix it in the appropriate ODD file(s) (also in GitHub). If it is not a real issue, sometimes the ticket will just be closed. If you do not have developer access on GitHub you'll to ask to be added to the Council team there. Otherwise, it's discussed either by email on the Council mailing list or at a Council meeting (conference call or in-person meeting). Comments are recorded in the ticket reflecting the decision reached, and changes are made in GitHub by a member of the Council sometime thereafter.
# The change shows up on tei-c.org after the next TEI "release", which happens about two or three times a year.

However, Council does sometimes consider lengthy proposals circulated to Council outside of GitHub and vote on them as packages, with the changes grouped together in a sensible way so they can be considered in smaller packages, or with the changes listed individually.

=== And what is its scope? ===

The Council's primary responsibility is to act as technical watchdog for the intellectual content of the TEI Guidelines. That is to say: it has the final say in just about every aspect of the TEI encoding scheme -- what elements exist in it, what they are called, how they should be used.

=== How do I join the TEI Council mailing list? ===

We have had the practice on the Council so far that elected members get added immediately to the list (and to the telecon, if there is one), with every right to participate, while outgoing members stay on until the end of their term. To join or discuss any problems using the list contact the [mailto:tei-council-owner@lists.tei-c.org TEI Council mailing list owner], currently this is Kevin Hawkins (North Texas) and Nick Homenda (Indiana). There is also a joint Board/Council mailing list to which you should be added as well.

=== Why are some people on the Council email list or attending Council meetings even though they are not on the list of elected members? ===

In addition to the members of the Council, the chair of the TEI Technical Council may invite others not elected to the Council to meetings (e.g. to speak to a particular issue). Historically the Council often invited a representative of the Board to the Council mailing list and meetings. The TEI-C Webmaster (currently Kevin Hawkins) and Assistant Webmaster (Nick Homenda) are also on the mailing lists.

=== What are the various job roles on the TEI Council? ===

==== TEI Technical Council Member ====
A TEI Technical Council Member is expected to participate in all aspects of Council work. This means that they should learn how the TEI infrastructure is organised and [http://www.tei-c.org/Activities/Council/Working/tcw20.xml how to edit the TEI Guidelines], asking on the Council list any questions they might have. They will be expected to come to face-to-face ("f2f") meetings (often two per year) and participate in a couple other teleconferences per year. They will be assigned (or take) feature requests/bugs on [https://github.com/TEIC the TEI Consortium's GitHub site], for which they will be in charge of encouraging discussion, reporting on the issue to Council, and eventually implementing (or ensuring implementation) of the resulting decision. A TEI Technical Council Member is expected to participate in the maintenance and development of the TEI Guidelines and related outputs. Some elected TEI Council members focus more on particular aspects of the infrastructure or stylesheets as part of the contribution to the Council. Council members should always act to represent what they believe are the opinions and best interest of the community that has elected them.

==== TEI Technical Council Chair ====
The TEI Technical Council Chair's role is to administrate and facilitate the work of the TEI Technical Council. If all of the Council are the elected servants of the community, then the Council Chair is the servant of the servants of the TEI (''Servus servorum TEI''). The duties of the Technical Council Chair include (in no particular order):
* ensuring the delivery and maintenance of the Guidelines
* arranging for Council members to actively participate in Council activities
* arranging and chairing the face-to-face meetings (in conjunction with the local organiser)
* arranging and chairing the teleconferences
* creating agendas for those meetings, and ensuring minutes are written and posted of them
* assigning tickets in [http://github.com/TEIC/ the TEIC Github organization]
* acting as SIG coordinator
* liaising for and reporting on Council activities at all Board meetings
* reflecting Council wishes in Board discussions
* acting as a public point of contact and responding to technical enquiries (messages to council@tei-c.org are forwarded to the Council Chair)
* announcing new releases of the Guidelines on the TEI-L mailing list
* ensuring the smooth running of the TEI Technical Council

The TEI Technical Council Chair is also a member of the Council, so has all the duties and obligations of being a council member as well.

==== Release Technician ====
The TEI Guidelines release process (see [http://www.tei-c.org/Activities/Council/Working/tcw22.xml tcw22: Building a TEI Release]) involves a single individual responsible for 'pushing the button' and completing the steps required to make a TEI Guidelines release live. This is not a standing position; instead, the responsibility rotates for every release in order to demystify the release process and spread the expertise beyond Oxford staff. Although we have documented the work in quite a detailed manner, it is a non-trivial process and involves a fair degree of work. A release technician is usually required to set aside a whole day for the release process since history teaches us that often the entire process needs to be re-run to correct last-minute errors.

==== TEI-C Webmaster and Assistant Webmaster ====

The TEI-C Webmaster and Assistant Webmaster are not officially part of the Council but may be added to the mailing lists at the discretion of the Council Chair. They are responsible for the smooth running of the TEI-C Website.

=== How is the TEI Technical Council Chair elected? ===

The [http://www.tei-c.org/About/bylaws.xml#body.1_div.3_div.3 Bylaws of the TEI-C] say that:
<blockquote>
The Chair of the Technical Council shall be elected by the voting Members of the TEI-C Technical Council from its membership and shall serve as the chief technical officer of the Consortium. If no Technical Council Member is able or willing to assume the chair, the Technical Council may request the Board of Directors to second one of its elected members to the role, or it may nominate a non-elected individual.
</blockquote>
This leaves it intentionally vague as to the precise process the TEI Technical Council will follow. For now there is vague consensus that they will do something like the following. Note that timeframes below are not intended to be rigid or precise, but rather to be suggestive.
# The new Technical Council Members will be added to the tei-council (and tei-board-council) mailing lists shortly after the members' meeting. Up until around the last last Friday in November those who are Council members for next year will consider whether they want to run to be Chair of the TEI Technical Council. The current Chair will facilitate this process by answering any questions about the post. Before that date those intending to stand should send a statement of some sort to the Council mailing list detailing why they think the council members should vote for them.
# On or around the first weekday of December if only one person is running then the Chair will announce this to the tei-council mailing list as an acclamation (and after a short period for objections, to the Board and TEI-L). If multiple people are running, then the Council Chair will appoint a "returning officer" who is not a member of the incoming Council (i.e., not a voter and thus at least a somewhat disinterested party). The returning officer will set up an electronic voting system with the names of the candidates. This should be a private election with no one able to determine who has voted for whom. E.g. if using opavote.org this should have the following settings:
## Results only shown at end
## Method: "Plurality/FPTP/SNTV" for 2 candidates, "Instant Runoff Voting" for 3 or more
## a single winner
## Ballot type: "choose one" for 2 candidates, "ranked enhanced" for 3 or more
## candidate order shuffled
# The returning officer should ensure the election runs for at least 4 days, preferably in early December, after announcing it on the tei-council mailing list (and distributing ballots depending on the system).
# The results will be announced publicly on the tei-council mailing list, and Council members given a brief chance to raise any objections with the election before the current Chair informs the Board and announces it more publicly on TEI-L.
# The new Chair assumes the role on 1 January. The current chair steps down on 31 December. The outgoing and incoming chairs should co-ordinate activities between the election and 1 January so as to ensure a smooth transition. (Remembering that the current Chair might be departing off council at the end of that year.) These dates and timescales can of course shift and are not meant to be set in stone.

== Terminology ==

=== What was the War on Free-text-bearing Attribute Values? ===

The War on Free-text-bearing Attribute Values, also known as the War on Free-text-bearing Attributes and the War on Attributes for short, happened because some have felt that if attribute values don't have a datatype, they are more prone to abuse than if they did. So there has been an effort to give datatypes to as many attributes as possible. Some discussion of this with respect to @rend is available here: http://blogs.oucs.ox.ac.uk/jamesc/2011/12/01/rend-and-the-war-on-text-bearing-attributes/

=== What is the "Birnbaum doctrine"? ===

As expressed in [http://www.tei-c.org/Activities/Council/Working/tcw09.xml TCW09: Backward Compatibility and the Maintenance of the Text Encoding Initiative Guidelines], we should avoid breaking backward compatibility and only do so after serious consideration. It does not mean that we cannot break backwards compatibility, just that we've agreed a set of steps to take when we do so. Our deprecation policy supersedes some of this.

=== In what ways will Council break backwards compatibility? ===

For an egregious error, we might actually change a content model immediately. More often, we will survey the community on TEI-L before doing so, and we might [[Practices no longer recommended or now deprecated|deprecate]].

=== What is the "Durand Conundrum"? ===

The "Durand Conundrum" was suggested by David G. Durand concerning the TEI's decision to use the [[ODD | TEI ODD]] meta-schema language rather than just one of the existing schema languages. Given that we decided to use our own language, why use RelaxNG as part of that language for describing content models? Generally, the consensus is that [[ODD | TEI ODD]] gives us greater power and flexibility than any individual schema language can do in that we can model things that those schema languages are currently unable to cope with. TEI ODD gives the ability for a single document to produce both documentation and schema since these are inherently interlinked. It also keeps the TEI honest, in requiring it to use its own system to document schemas. [[ODD | TEI ODD]] does currently have some problems, a few of which are detailed at [[ODD-dev]] and successive revisions of TEI ODD are intended to solve some of these. Increasingly [[ODD#Future_plans:_.22Pure_ODD.22|the work on Pure ODD elements for content models and datatypes]] has cut the gordian knot of this problem.

=== What does "no magic" mean? ===

'Magic' in the sense sometimes used in Council discussion refers to pre-existing or special knowledge required to process something. For example, it was only by 'magic' that a TEI ODD processor would know to add attributes from the att.global attribute class to elements until this was changed to make all element specifications have to explicitly claim membership in this class if they wanted the global attributes. Knowing to add them was 'magic', and in general it is better if any requirements or understood knowledge is explicitly documented. While some 'magic' of understood conventions or processing will always remain in complex technical systems, the Council strives to at very least enable the possibility of documenting the underlying rules when it discovers them. James Cummings has been a fervent proponent of the removal of any understood 'magic' rules from the TEI.

=== What is a "magic token"? ===

This is an value, usually an attribute value, such as that of @key or @rend, which does not follow a standard outside vocabulary but instead is understood in some undocumented way and often used for local processing. It should usually be explained in the teiHeader if possible. Having any processing rely on undocumented magic tokens is generally considered a bad idea. See also [http://en.wikipedia.org/wiki/Magic_cookie Magic Cookie].

=== What is a non-deterministic content model? ===

If you have a content model for <tt><a></tt>:

<code>
b*, c?, b*
</code>

and you have a document with:

<pre>
<a>

</a>
</pre>

then a parser can't tell whether the <tt></tt> matches the first <tt>b*</tt> or the second <tt>b*</tt> in the content model. Thus, the content model itself is called “non-determinstic”. DTDs and W3C XML Schemas reject non-deterministic content models. Thus, if we were to create one in the TEI, validation with DTD and XSD would fail due to errors ''in the schema'', regardless of whether the instance document has an occurence that is non-deterministic or not.

=== What are Janus elements? ===

These are pairs of elements that are in a sense two sides of the same coin, such as orig and reg, corr and sic, abbr and expan.

=== What does it mean to say that elements tessellate? ===

This means that all textual content is included in exactly one instance of an element. For example, once you start using divs (numbered or unnumbered), all text thereafter must be inside of one of the divs: you can't start using p elements that are not wrapped in a div.

In the Guidelines this is sometimes referred to as end-to-end segmentation.

== Meetings ==

=== Where are the minutes of previous meetings? ===

Minutes are [http://www.tei-c.org/Activities/Council/Meetings/index.xml archived on the TEI website]. Interim states of minutes may at times live in this wiki, Google Docs, or elsewhere.

=== How are the teleconferences held? ===

Currently the TEI Council uses the teleconferencing facilities provided by commercial provider since this has proved most cost effective with less problems than other VOIP-based solutions. This has 800/free call numbers for most countries, and low-cost for some. This will be set up by the Council Chair in advance and details posted to the list.

The specific details of what number to dial and what access code is needed will be circulated on the council list shortly before the meeting.

=== What funding is available for Council Activities? And how do I get reimbursed? ===

The TEI funds the participation of the council members in the meetings. Though I don't know of anyone claiming back telephone conferencing costs, I suppose that is possible as well, in most cases the council members' institutions probably swallow that.

If the council has a meeting, then the council members' travel, hotel, etc. will be reimbursed with proper receipts. The TEI reimburses all reasonable expenses in keeping with standard practice at most universities and granting agencies. We cover meals, travel, lodging, and other common daily travel expenses. Airfare should be economy class and direct return, unless otherwise arranged with the Treasurer prior to your trip. (See [http://www.tei-c.org/Board/procedures.xml#body.1_div.8 draft reimbursement policies and procedures].) If you have questions about reimbursement procedures, including what is reimbursable, please email John Unsworth, the TEI treasurer, at john.m.unsworth AT gmail.com.

Use the TEI Travel expense form available here: https://www.tei-c.org/wp-content/uploads/2017/10/TEI_travel_form.pdf '''Expense forms should be submitted within 10 days of the end of the meeting.'''

Council members are not funded to attend the TEI Members' Meeting, however, there has been discussion concerning whether the council should also officially meet here as well.

== How we get work done ==

=== I have something to say about a GitHub Feature Request or Bug: Should I comment on the issue or the TEI Council mailing list? ===

There is no hard-and-fast policy on this. The mailing list is a better place for ongoing discussions where people are arguing back and forth during decision making. The GitHub tracker is the appropriate place to record opinions, positions, and decisions for posterity, especially if such would help a) whoever is implementing the decisions recorded in the ticket, b) anyone revisiting this decision later to retrace the thinking. The [http://lists.tei-c.org/pipermail/tei-council/ TEI Council mailing list archives] are public, so if substantial discussion has taken place there (or indeed on TEI-L), this can also be linked to from the ticket.

=== When is discussion on an element or topic "closed" and how do I know? ===

Any topic can be revisited at any point, even in the published guidelines, through posting a feature request on GitHub. Council-specific issues should be raised on the council mailing list, after having reviewed any previous discussion on the topic in the [http://lists.tei-c.org/pipermail/tei-council/ tei-council mailing list archives].

=== How can I find out about every time a ticket is created or commented on? ===

Each repository has a "watch" control, which is to be found on the top right or the repo's GitHub page, below the navigation bar. This control lets you manage notifications in various ways.

=== How are tickets assigned in GitHub? ===
All members of Council are made part of the Council Team on the GitHub TEIC Organisation and meant to take an active role in the development and maintenance of the TEI Guidelines. This means that they have write access to the TEI Guidelines Github Repository, and tickets can be assigned to them in the ticket trackers. They can also update and modify tickets. This means that Council members are free to 'take' tickets which they wish to oversee. Other Council members can also 'give' tickets to each other if they think someone particularly suited to overseeing a particular ticket. (However, usually they should have the Council member's permission to do so.) On a regular basis the Council Chair will assign tickets to Council members, if a ticket gets assigned to them that they don't want to do they should tell the Chair and/or ask other Council members to swap.

=== What do the issue labels mean? ===

* 'Status: Blocked' means that the issue cannot be progressed because it requires either that another issue be completed first or that more information is needed from the reporter or a third party.

* 'Status: Needs Discussion' means that the issue has not been talked about enough yet to resolve it. New issues nearly always go into this status first. When Council has face-to-face meetings, these are usually the issues we target first.

* 'Status: Go' means that the ticket has been discussed, there is general consensus on what the correct thing to do is, and it has been assigned for someone to ensure its implementation.

* Other labels should be self-explanatory, and are sometimes created as needed to group tickets for various purposes.

=== How does a TEI release happen? ===

The process of making a release is documented at http://www.tei-c.org/Activities/Council/Working/tcw22.xml

== Working in GitHub ==

=== How do I edit the TEI Guidelines? ===

Editing the TEI Guidelines is a complex process and the Council has produced a document http://www.tei-c.org/Activities/Council/Working/tcw20.xml covering the logical and physical layout of the Guidelines, stylistic notes, how to make a change to the Guidelines (it requires [[TEI-Council-FAQ#How_do_I_use_GitHub.3F|using subversion]], building a release, and a reference section of useful information. If any information you need isn't in this document, ask on the Council list and get someone to update it!

=== How can I find out about every time a change is made in the TEI GitHub repository? ===
# Go to https://github.com/TEIC/
# Make sure you are logged in and
# go into each repository you are interested in and 'watch' them.

=== How do I use GitHub? ===
The TEI stores its working files in repositories in the [https://github.com/TEIC TEIC GitHub Organization]. See the [http://www.tei-c.org/guidelines/p5/using-the-tei-github-repository/ instructions]. Write access is reserved for those who are on the TEI Council or TEI Contributors teams. Any Council member should be able to add you to the Council team.

=== What should I put in a GitHub commit message? ===

It is beneficial to all those looking at the TEI GitHub repository if commit messages are clear and detailed. This is especially true when trying to revert changes made by yourself or others to solve problems. A good commit message will include:
* a subject line less than 72 characters long (which may be the whole message if no more is needed)
* an explanation to a useful level of detail about what you did
* a mention of why this is being done
* the GitHub issue numbers (or urls) that relate to the change if applicable
* an explanation of whether this change is completing the work described or one step towards doing so.

== TEI website ==

=== I want to add a document to add meeting minutes, reports, or working papers to the TEI-C website. How do I do that? ===

The TEI webmasters -- currently Kevin Hawkins and Nick Homenda -- have access to the CMS behind the TEI website. The site uses a stylesheet to render TEI Lite documents in XHTML, though the CMS can also deliver non-TEI documents. However, for long-term preservation and consistency, use of TEI Lite is encouraged.

You can author a document from scratch or take an existing document as a starting point. To get the XML source of an existing document, simply click "XML View" in the footer of a page on the TEI-C website and choose "save as" in your browser.

The TEI has a longstanding naming convention for files that consists of:

# a short alphabetical abbreviation for a committee (such as "tc" for "Technical Council")
# a one-letter abbreviation for minutes ("m"), reports ("r"), or working papers ("w")
# a two-digit number for the document with a committee series, numbered sequentially (e.g., "tcw01" is the first working paper from the Technical Council, "tcm05" is the fifth minutes from the Technical Council, etc.)

There is no registry of documents, so when creating a new one, you simply name the file appropriately.

Send the file to a webmaster for putting online. If you are hesitant to have the page go live until you have previewed it, you can ask the webmaster to send you a derived HTML version using the stylesheets without publishing that document.

=== How do I get access to the Google Analytics Data for www.tei-c.org? ===

Email the TEI-C webmaster: web@tei-c.org.

== Miscellaneous ==

=== Why do some elements have @type and others do not? ===

The TEI has avoided adding @type globally to elements because its availability is thought to invite tag or attribute abuse. In order for a request to add @type to an element to be considered for prolonged discussion and argument the TEI Technical Council has a standing principle that an element should be both repeatable and have obvious different classifications that apply to it. If such a request is approved then the preferred method is to make the element a member of the att.typed class (because if you can have @type, you can also have sub-types and thus need @subtype). If a closed or suggested value list, or different description is needed, this should then be provided as a local modification to the attributes inherited from att.typed.

== I have a question! ==

Then add it just above this one or email someone on the council or the council list reminding them of the existence of this wiki page when you ask your question.

[[Category:Council]]

TEI-Council-FAQ

2019-10-08T14:25:51Z

Hcayless: /* How we get work done */

So you have some questions about how the [[Council|TEI Technical Council]] works? This page has been set up to answer questions that new council members (or other curious parties) may have.

== Overview ==

=== How does the Council do its work? ===

By every means possible. These include regular telephone conferences, endless streams of email, widely circulated discussion documents, private caucussing, public debate in other contexts such as TEI-L, and private gossip. Formally speaking, the Council meets face to face once a year (at least), and many more times than that virtually.

=== And what work does it do? ===

You should probably review the recent official work of the Council by reading the last few sets of minutes: http://www.tei-c.org/Council/ has an index page which links to them all (when we remember to update it). The minutes record topics discussed and responsibilities allocated at the Council level. Of course many Council members are also active in subgroups (formal or informal) of the Council or SIGs, which may be documented elsewhere as well.

Generally, things in Council work like this:

# A bug report or feature request is reported by anyone at [https://github.com/TEIC/ GitHub] for the [https://github.com/TEIC/TEI/issues Guidelines] or [https://github.com/TEIC/Stylesheets/issues Stylesheets].
# Sometimes others notice the ticket and comment on it.
# Sometimes a Council member may make an executive decision on the ticket. If it's a corrigible error or bug, we can just fix it in the appropriate ODD file(s) (also in GitHub). If it is not a real issue, sometimes the ticket will just be closed. If you do not have developer access on GitHub you'll to ask to be added to the Council team there. Otherwise, it's discussed either by email on the Council mailing list or at a Council meeting (conference call or in-person meeting). Comments are recorded in the ticket reflecting the decision reached, and changes are made in GitHub by a member of the Council sometime thereafter.
# The change shows up on tei-c.org after the next TEI "release", which happens about two or three times a year.

However, Council does sometimes consider lengthy proposals circulated to Council outside of GitHub and vote on them as packages, with the changes grouped together in a sensible way so they can be considered in smaller packages, or with the changes listed individually.

=== And what is its scope? ===

The Council's primary responsibility is to act as technical watchdog for the intellectual content of the TEI Guidelines. That is to say: it has the final say in just about every aspect of the TEI encoding scheme -- what elements exist in it, what they are called, how they should be used.

=== How do I join the TEI Council mailing list? ===

We have had the practice on the Council so far that elected members get added immediately to the list (and to the telecon, if there is one), with every right to participate, while outgoing members stay on until the end of their term. To join or discuss any problems using the list contact the [mailto:tei-council-owner@lists.tei-c.org TEI Council mailing list owner], currently this is Kevin Hawkins (North Texas) and Nick Homenda (Indiana). There is also a joint Board/Council mailing list to which you should be added as well.

=== Why are some people on the Council email list or attending Council meetings even though they are not on the list of elected members? ===

In addition to the members of the Council, the chair of the TEI Technical Council may invite others not elected to the Council to meetings (e.g. to speak to a particular issue). Historically the Council often invited a representative of the Board to the Council mailing list and meetings. The TEI-C Webmaster (currently Kevin Hawkins) and Assistant Webmaster (Nick Homenda) are also on the mailing lists.

=== What are the various job roles on the TEI Council? ===

==== TEI Technical Council Member ====
A TEI Technical Council Member is expected to participate in all aspects of Council work. This means that they should learn how the TEI infrastructure is organised and [http://www.tei-c.org/Activities/Council/Working/tcw20.xml how to edit the TEI Guidelines], asking on the Council list any questions they might have. They will be expected to come to face-to-face ("f2f") meetings (often two per year) and participate in a couple other teleconferences per year. They will be assigned (or take) feature requests/bugs on [https://github.com/TEIC the TEI Consortium's GitHub site], for which they will be in charge of encouraging discussion, reporting on the issue to Council, and eventually implementing (or ensuring implementation) of the resulting decision. A TEI Technical Council Member is expected to participate in the maintenance and development of the TEI Guidelines and related outputs. Some elected TEI Council members focus more on particular aspects of the infrastructure or stylesheets as part of the contribution to the Council. Council members should always act to represent what they believe are the opinions and best interest of the community that has elected them.

==== TEI Technical Council Chair ====
The TEI Technical Council Chair's role is to administrate and facilitate the work of the TEI Technical Council. If all of the Council are the elected servants of the community, then the Council Chair is the servant of the servants of the TEI (''Servus servorum TEI''). The duties of the Technical Council Chair include (in no particular order):
* ensuring the delivery and maintenance of the Guidelines
* arranging for Council members to actively participate in Council activities
* arranging and chairing the face-to-face meetings (in conjunction with the local organiser)
* arranging and chairing the teleconferences
* creating agendas for those meetings, and ensuring minutes are written and posted of them
* assigning tickets in [http://github.com/TEIC/ the TEIC Github organization]
* acting as SIG coordinator
* liaising for and reporting on Council activities at all Board meetings
* reflecting Council wishes in Board discussions
* acting as a public point of contact and responding to technical enquiries (messages to council@tei-c.org are forwarded to the Council Chair)
* announcing new releases of the Guidelines on the TEI-L mailing list
* ensuring the smooth running of the TEI Technical Council

The TEI Technical Council Chair is also a member of the Council, so has all the duties and obligations of being a council member as well.

==== Release Technician ====
The TEI Guidelines release process (see [http://www.tei-c.org/Activities/Council/Working/tcw22.xml tcw22: Building a TEI Release]) involves a single individual responsible for 'pushing the button' and completing the steps required to make a TEI Guidelines release live. This is not a standing position; instead, the responsibility rotates for every release in order to demystify the release process and spread the expertise beyond Oxford staff. Although we have documented the work in quite a detailed manner, it is a non-trivial process and involves a fair degree of work. A release technician is usually required to set aside a whole day for the release process since history teaches us that often the entire process needs to be re-run to correct last-minute errors.

==== TEI-C Webmaster and Assistant Webmaster ====

The TEI-C Webmaster and Assistant Webmaster are not officially part of the Council but may be added to the mailing lists at the discretion of the Council Chair. They are responsible for the smooth running of the TEI-C Website.

=== How is the TEI Technical Council Chair elected? ===

The [http://www.tei-c.org/About/bylaws.xml#body.1_div.3_div.3 Bylaws of the TEI-C] say that:
<blockquote>
The Chair of the Technical Council shall be elected by the voting Members of the TEI-C Technical Council from its membership and shall serve as the chief technical officer of the Consortium. If no Technical Council Member is able or willing to assume the chair, the Technical Council may request the Board of Directors to second one of its elected members to the role, or it may nominate a non-elected individual.
</blockquote>
This leaves it intentionally vague as to the precise process the TEI Technical Council will follow. For now there is vague consensus that they will do something like the following. Note that timeframes below are not intended to be rigid or precise, but rather to be suggestive.
# The new Technical Council Members will be added to the tei-council (and tei-board-council) mailing lists shortly after the members' meeting. Up until around the last last Friday in November those who are Council members for next year will consider whether they want to run to be Chair of the TEI Technical Council. The current Chair will facilitate this process by answering any questions about the post. Before that date those intending to stand should send a statement of some sort to the Council mailing list detailing why they think the council members should vote for them.
# On or around the first weekday of December if only one person is running then the Chair will announce this to the tei-council mailing list as an acclamation (and after a short period for objections, to the Board and TEI-L). If multiple people are running, then the Council Chair will appoint a "returning officer" who is not a member of the incoming Council (i.e., not a voter and thus at least a somewhat disinterested party). The returning officer will set up an electronic voting system with the names of the candidates. This should be a private election with no one able to determine who has voted for whom. E.g. if using opavote.org this should have the following settings:
## Results only shown at end
## Method: "Plurality/FPTP/SNTV" for 2 candidates, "Instant Runoff Voting" for 3 or more
## a single winner
## Ballot type: "choose one" for 2 candidates, "ranked enhanced" for 3 or more
## candidate order shuffled
# The returning officer should ensure the election runs for at least 4 days, preferably in early December, after announcing it on the tei-council mailing list (and distributing ballots depending on the system).
# The results will be announced publicly on the tei-council mailing list, and Council members given a brief chance to raise any objections with the election before the current Chair informs the Board and announces it more publicly on TEI-L.
# The new Chair assumes the role on 1 January. The current chair steps down on 31 December. The outgoing and incoming chairs should co-ordinate activities between the election and 1 January so as to ensure a smooth transition. (Remembering that the current Chair might be departing off council at the end of that year.) These dates and timescales can of course shift and are not meant to be set in stone.

== Terminology ==

=== What was the War on Free-text-bearing Attribute Values? ===

The War on Free-text-bearing Attribute Values, also known as the War on Free-text-bearing Attributes and the War on Attributes for short, happened because some have felt that if attribute values don't have a datatype, they are more prone to abuse than if they did. So there has been an effort to give datatypes to as many attributes as possible. Some discussion of this with respect to @rend is available here: http://blogs.oucs.ox.ac.uk/jamesc/2011/12/01/rend-and-the-war-on-text-bearing-attributes/

=== What is the "Birnbaum doctrine"? ===

As expressed in [http://www.tei-c.org/Activities/Council/Working/tcw09.xml TCW09: Backward Compatibility and the Maintenance of the Text Encoding Initiative Guidelines], we should avoid breaking backward compatibility and only do so after serious consideration. It does not mean that we cannot break backwards compatibility, just that we've agreed a set of steps to take when we do so. Our deprecation policy supersedes some of this.

=== In what ways will Council break backwards compatibility? ===

For an egregious error, we might actually change a content model immediately. More often, we will survey the community on TEI-L before doing so, and we might [[Practices no longer recommended or now deprecated|deprecate]].

=== What is the "Durand Conundrum"? ===

The "Durand Conundrum" was suggested by David G. Durand concerning the TEI's decision to use the [[ODD | TEI ODD]] meta-schema language rather than just one of the existing schema languages. Given that we decided to use our own language, why use RelaxNG as part of that language for describing content models? Generally, the consensus is that [[ODD | TEI ODD]] gives us greater power and flexibility than any individual schema language can do in that we can model things that those schema languages are currently unable to cope with. TEI ODD gives the ability for a single document to produce both documentation and schema since these are inherently interlinked. It also keeps the TEI honest, in requiring it to use its own system to document schemas. [[ODD | TEI ODD]] does currently have some problems, a few of which are detailed at [[ODD-dev]] and successive revisions of TEI ODD are intended to solve some of these. Increasingly [[ODD#Future_plans:_.22Pure_ODD.22|the work on Pure ODD elements for content models and datatypes]] has cut the gordian knot of this problem.

=== What does "no magic" mean? ===

'Magic' in the sense sometimes used in Council discussion refers to pre-existing or special knowledge required to process something. For example, it was only by 'magic' that a TEI ODD processor would know to add attributes from the att.global attribute class to elements until this was changed to make all element specifications have to explicitly claim membership in this class if they wanted the global attributes. Knowing to add them was 'magic', and in general it is better if any requirements or understood knowledge is explicitly documented. While some 'magic' of understood conventions or processing will always remain in complex technical systems, the Council strives to at very least enable the possibility of documenting the underlying rules when it discovers them. James Cummings has been a fervent proponent of the removal of any understood 'magic' rules from the TEI.

=== What is a "magic token"? ===

This is an value, usually an attribute value, such as that of @key or @rend, which does not follow a standard outside vocabulary but instead is understood in some undocumented way and often used for local processing. It should usually be explained in the teiHeader if possible. Having any processing rely on undocumented magic tokens is generally considered a bad idea. See also [http://en.wikipedia.org/wiki/Magic_cookie Magic Cookie].

=== What is a non-deterministic content model? ===

If you have a content model for <tt><a></tt>:

<code>
b*, c?, b*
</code>

and you have a document with:

<pre>
<a>

</a>
</pre>

then a parser can't tell whether the <tt></tt> matches the first <tt>b*</tt> or the second <tt>b*</tt> in the content model. Thus, the content model itself is called “non-determinstic”. DTDs and W3C XML Schemas reject non-deterministic content models. Thus, if we were to create one in the TEI, validation with DTD and XSD would fail due to errors ''in the schema'', regardless of whether the instance document has an occurence that is non-deterministic or not.

=== What are Janus elements? ===

These are pairs of elements that are in a sense two sides of the same coin, such as orig and reg, corr and sic, abbr and expan.

=== What does it mean to say that elements tessellate? ===

This means that all textual content is included in exactly one instance of an element. For example, once you start using divs (numbered or unnumbered), all text thereafter must be inside of one of the divs: you can't start using p elements that are not wrapped in a div.

In the Guidelines this is sometimes referred to as end-to-end segmentation.

== Meetings ==

=== Where are the minutes of previous meetings? ===

Minutes are [http://www.tei-c.org/Activities/Council/Meetings/index.xml archived on the TEI website]. Interim states of minutes may at times live in this wiki, Google Docs, or elsewhere.

=== How are the teleconferences held? ===

Currently the TEI Council uses the teleconferencing facilities provided by commercial provider since this has proved most cost effective with less problems than other VOIP-based solutions. This has 800/free call numbers for most countries, and low-cost for some. This will be set up by the Council Chair in advance and details posted to the list.

The specific details of what number to dial and what access code is needed will be circulated on the council list shortly before the meeting.

=== What funding is available for Council Activities? And how do I get reimbursed? ===

The TEI funds the participation of the council members in the meetings. Though I don't know of anyone claiming back telephone conferencing costs, I suppose that is possible as well, in most cases the council members' institutions probably swallow that.

If the council has a meeting, then the council members' travel, hotel, etc. will be reimbursed with proper receipts. The TEI reimburses all reasonable expenses in keeping with standard practice at most universities and granting agencies. We cover meals, travel, lodging, and other common daily travel expenses. Airfare should be economy class and direct return, unless otherwise arranged with the Treasurer prior to your trip. (See [http://www.tei-c.org/Board/procedures.xml#body.1_div.8 draft reimbursement policies and procedures].) If you have questions about reimbursement procedures, including what is reimbursable, please email John Unsworth, the TEI treasurer, at john.m.unsworth AT gmail.com.

Use the TEI Travel expense form available here: https://www.tei-c.org/wp-content/uploads/2017/10/TEI_travel_form.pdf '''Expense forms should be submitted within 10 days of the end of the meeting.'''

Council members are not funded to attend the TEI Members' Meeting, however, there has been discussion concerning whether the council should also officially meet here as well.

== How we get work done ==

=== I have something to say about a GitHub Feature Request or Bug: Should I comment on the issue or the TEI Council mailing list? ===

There is no hard-and-fast policy on this. The mailing list is a better place for ongoing discussions where people are arguing back and forth during decision making. The GitHub tracker is the appropriate place to record opinions, positions, and decisions for posterity, especially if such would help a) whoever is implementing the decisions recorded in the ticket, b) anyone revisiting this decision later to retrace the thinking. The [http://lists.tei-c.org/pipermail/tei-council/ TEI Council mailing list archives] are public, so if substantial discussion has taken place there (or indeed on TEI-L), this can also be linked to from the ticket.

=== When is discussion on an element or topic "closed" and how do I know? ===

Any topic can be revisited at any point, even in the published guidelines, through posting a feature request on GitHub. Council-specific issues should be raised on the council mailing list, after having reviewed any previous discussion on the topic in the [http://lists.tei-c.org/pipermail/tei-council/ tei-council mailing list archives].

=== How can I find out about every time a ticket is created or commented on? ===

Each repository has a "watch" control, which is to be found on the top right or the repo's GitHub page, below the navigation bar. This control lets you manage notifications in various ways.

=== How are tickets assigned in GitHub? ===
All members of Council are made part of the Council Team on the GitHub TEIC Organisation and meant to take an active role in the development and maintenance of the TEI Guidelines. This means that they have write access to the TEI Guidelines Github Repository, and tickets can be assigned to them in the ticket trackers. They can also update and modify tickets. This means that Council members are free to 'take' tickets which they wish to oversee. Other Council members can also 'give' tickets to each other if they think someone particularly suited to overseeing a particular ticket. (However, usually they should have the Council member's permission to do so.) On a regular basis the Council Chair will assign tickets to Council members, if a ticket gets assigned to them that they don't want to do they should tell the Chair and/or ask other Council members to swap.

=== What do the ticket labels mean? ===

* 'Status: Blocked' means that the issue cannot be progressed because it requires either that another issue be completed first or that more information is needed from the reporter or a third party.

* 'Status: Needs Discussion' means that the issue has not been talked about enough yet to resolve it. New issues nearly always go into this status first. When Council has face-to-face meetings, these are usually the issues we target first.

* 'Status: Go' means that the ticket has been discussed, there is general consensus on what the correct thing to do is, and it has been assigned for someone to ensure its implementation.

* Other labels should be self-explanatory, and are sometimes created as needed to group tickets for various purposes.

=== How does a TEI release happen? ===

The process of making a release is documented at http://www.tei-c.org/Activities/Council/Working/tcw22.xml

== Working in GitHub ==

=== How do I edit the TEI Guidelines? ===

Editing the TEI Guidelines is a complex process and the Council has produced a document http://www.tei-c.org/Activities/Council/Working/tcw20.xml covering the logical and physical layout of the Guidelines, stylistic notes, how to make a change to the Guidelines (it requires [[TEI-Council-FAQ#How_do_I_use_GitHub.3F|using subversion]], building a release, and a reference section of useful information. If any information you need isn't in this document, ask on the Council list and get someone to update it!

=== How can I find out about every time a change is made in the TEI GitHub repository? ===
# Go to https://github.com/TEIC/
# Make sure you are logged in and
# go into each repository you are interested in and 'watch' them.

=== How do I use GitHub? ===
The TEI stores its working files in repositories in the [https://github.com/TEIC TEIC GitHub Organization]. See the [http://www.tei-c.org/guidelines/p5/using-the-tei-github-repository/ instructions]. Write access is reserved for those who are on the TEI Council or TEI Contributors teams. Any Council member should be able to add you to the Council team.

=== What should I put in a GitHub commit message? ===

It is beneficial to all those looking at the TEI GitHub repository if commit messages are clear and detailed. This is especially true when trying to revert changes made by yourself or others to solve problems. A good commit message will include:
* a subject line less than 72 characters long (which may be the whole message if no more is needed)
* an explanation to a useful level of detail about what you did
* a mention of why this is being done
* the GitHub issue numbers (or urls) that relate to the change if applicable
* an explanation of whether this change is completing the work described or one step towards doing so.

== TEI website ==

=== I want to add a document to add meeting minutes, reports, or working papers to the TEI-C website. How do I do that? ===

The TEI webmasters -- currently Kevin Hawkins and Nick Homenda -- have access to the CMS behind the TEI website. The site uses a stylesheet to render TEI Lite documents in XHTML, though the CMS can also deliver non-TEI documents. However, for long-term preservation and consistency, use of TEI Lite is encouraged.

You can author a document from scratch or take an existing document as a starting point. To get the XML source of an existing document, simply click "XML View" in the footer of a page on the TEI-C website and choose "save as" in your browser.

The TEI has a longstanding naming convention for files that consists of:

# a short alphabetical abbreviation for a committee (such as "tc" for "Technical Council")
# a one-letter abbreviation for minutes ("m"), reports ("r"), or working papers ("w")
# a two-digit number for the document with a committee series, numbered sequentially (e.g., "tcw01" is the first working paper from the Technical Council, "tcm05" is the fifth minutes from the Technical Council, etc.)

There is no registry of documents, so when creating a new one, you simply name the file appropriately.

Send the file to a webmaster for putting online. If you are hesitant to have the page go live until you have previewed it, you can ask the webmaster to send you a derived HTML version using the stylesheets without publishing that document.

=== How do I get access to the Google Analytics Data for www.tei-c.org? ===

Email the TEI-C webmaster: web@tei-c.org.

== Miscellaneous ==

=== Why do some elements have @type and others do not? ===

The TEI has avoided adding @type globally to elements because its availability is thought to invite tag or attribute abuse. In order for a request to add @type to an element to be considered for prolonged discussion and argument the TEI Technical Council has a standing principle that an element should be both repeatable and have obvious different classifications that apply to it. If such a request is approved then the preferred method is to make the element a member of the att.typed class (because if you can have @type, you can also have sub-types and thus need @subtype). If a closed or suggested value list, or different description is needed, this should then be provided as a local modification to the attributes inherited from att.typed.

== I have a question! ==

Then add it just above this one or email someone on the council or the council list reminding them of the existence of this wiki page when you ask your question.

[[Category:Council]]

TEI-Council-FAQ

2019-10-08T13:52:32Z

Hcayless: /* How do I use GitHub? */

So you have some questions about how the [[Council|TEI Technical Council]] works? This page has been set up to answer questions that new council members (or other curious parties) may have.

== Overview ==

=== How does the Council do its work? ===

By every means possible. These include regular telephone conferences, endless streams of email, widely circulated discussion documents, private caucussing, public debate in other contexts such as TEI-L, and private gossip. Formally speaking, the Council meets face to face once a year (at least), and many more times than that virtually.

=== And what work does it do? ===

You should probably review the recent official work of the Council by reading the last few sets of minutes: http://www.tei-c.org/Council/ has an index page which links to them all (when we remember to update it). The minutes record topics discussed and responsibilities allocated at the Council level. Of course many Council members are also active in subgroups (formal or informal) of the Council or SIGs, which may be documented elsewhere as well.

Generally, things in Council work like this:

# A bug report or feature request is reported by anyone at [https://github.com/TEIC/ GitHub] for the [https://github.com/TEIC/TEI/issues Guidelines] or [https://github.com/TEIC/Stylesheets/issues Stylesheets].
# Sometimes others notice the ticket and comment on it.
# Sometimes a Council member may make an executive decision on the ticket. If it's a corrigible error or bug, we can just fix it in the appropriate ODD file(s) (also in GitHub). If it is not a real issue, sometimes the ticket will just be closed. If you do not have developer access on GitHub you'll to ask to be added to the Council team there. Otherwise, it's discussed either by email on the Council mailing list or at a Council meeting (conference call or in-person meeting). Comments are recorded in the ticket reflecting the decision reached, and changes are made in GitHub by a member of the Council sometime thereafter.
# The change shows up on tei-c.org after the next TEI "release", which happens about two or three times a year.

However, Council does sometimes consider lengthy proposals circulated to Council outside of GitHub and vote on them as packages, with the changes grouped together in a sensible way so they can be considered in smaller packages, or with the changes listed individually.

=== And what is its scope? ===

The Council's primary responsibility is to act as technical watchdog for the intellectual content of the TEI Guidelines. That is to say: it has the final say in just about every aspect of the TEI encoding scheme -- what elements exist in it, what they are called, how they should be used.

=== How do I join the TEI Council mailing list? ===

We have had the practice on the Council so far that elected members get added immediately to the list (and to the telecon, if there is one), with every right to participate, while outgoing members stay on until the end of their term. To join or discuss any problems using the list contact the [mailto:tei-council-owner@lists.tei-c.org TEI Council mailing list owner], currently this is Kevin Hawkins (North Texas) and Nick Homenda (Indiana). There is also a joint Board/Council mailing list to which you should be added as well.

=== Why are some people on the Council email list or attending Council meetings even though they are not on the list of elected members? ===

In addition to the members of the Council, the chair of the TEI Technical Council may invite others not elected to the Council to meetings (e.g. to speak to a particular issue). Historically the Council often invited a representative of the Board to the Council mailing list and meetings. The TEI-C Webmaster (currently Kevin Hawkins) and Assistant Webmaster (Nick Homenda) are also on the mailing lists.

=== What are the various job roles on the TEI Council? ===

==== TEI Technical Council Member ====
A TEI Technical Council Member is expected to participate in all aspects of Council work. This means that they should learn how the TEI infrastructure is organised and [http://www.tei-c.org/Activities/Council/Working/tcw20.xml how to edit the TEI Guidelines], asking on the Council list any questions they might have. They will be expected to come to face-to-face ("f2f") meetings (often two per year) and participate in a couple other teleconferences per year. They will be assigned (or take) feature requests/bugs on [https://github.com/TEIC the TEI Consortium's GitHub site], for which they will be in charge of encouraging discussion, reporting on the issue to Council, and eventually implementing (or ensuring implementation) of the resulting decision. A TEI Technical Council Member is expected to participate in the maintenance and development of the TEI Guidelines and related outputs. Some elected TEI Council members focus more on particular aspects of the infrastructure or stylesheets as part of the contribution to the Council. Council members should always act to represent what they believe are the opinions and best interest of the community that has elected them.

==== TEI Technical Council Chair ====
The TEI Technical Council Chair's role is to administrate and facilitate the work of the TEI Technical Council. If all of the Council are the elected servants of the community, then the Council Chair is the servant of the servants of the TEI (''Servus servorum TEI''). The duties of the Technical Council Chair include (in no particular order):
* ensuring the delivery and maintenance of the Guidelines
* arranging for Council members to actively participate in Council activities
* arranging and chairing the face-to-face meetings (in conjunction with the local organiser)
* arranging and chairing the teleconferences
* creating agendas for those meetings, and ensuring minutes are written and posted of them
* assigning tickets in [http://github.com/TEIC/ the TEIC Github organization]
* acting as SIG coordinator
* liaising for and reporting on Council activities at all Board meetings
* reflecting Council wishes in Board discussions
* acting as a public point of contact and responding to technical enquiries (messages to council@tei-c.org are forwarded to the Council Chair)
* announcing new releases of the Guidelines on the TEI-L mailing list
* ensuring the smooth running of the TEI Technical Council

The TEI Technical Council Chair is also a member of the Council, so has all the duties and obligations of being a council member as well.

==== Release Technician ====
The TEI Guidelines release process (see [http://www.tei-c.org/Activities/Council/Working/tcw22.xml tcw22: Building a TEI Release]) involves a single individual responsible for 'pushing the button' and completing the steps required to make a TEI Guidelines release live. This is not a standing position; instead, the responsibility rotates for every release in order to demystify the release process and spread the expertise beyond Oxford staff. Although we have documented the work in quite a detailed manner, it is a non-trivial process and involves a fair degree of work. A release technician is usually required to set aside a whole day for the release process since history teaches us that often the entire process needs to be re-run to correct last-minute errors.

==== TEI-C Webmaster and Assistant Webmaster ====

The TEI-C Webmaster and Assistant Webmaster are not officially part of the Council but may be added to the mailing lists at the discretion of the Council Chair. They are responsible for the smooth running of the TEI-C Website.

=== How is the TEI Technical Council Chair elected? ===

The [http://www.tei-c.org/About/bylaws.xml#body.1_div.3_div.3 Bylaws of the TEI-C] say that:
<blockquote>
The Chair of the Technical Council shall be elected by the voting Members of the TEI-C Technical Council from its membership and shall serve as the chief technical officer of the Consortium. If no Technical Council Member is able or willing to assume the chair, the Technical Council may request the Board of Directors to second one of its elected members to the role, or it may nominate a non-elected individual.
</blockquote>
This leaves it intentionally vague as to the precise process the TEI Technical Council will follow. For now there is vague consensus that they will do something like the following. Note that timeframes below are not intended to be rigid or precise, but rather to be suggestive.
# The new Technical Council Members will be added to the tei-council (and tei-board-council) mailing lists shortly after the members' meeting. Up until around the last last Friday in November those who are Council members for next year will consider whether they want to run to be Chair of the TEI Technical Council. The current Chair will facilitate this process by answering any questions about the post. Before that date those intending to stand should send a statement of some sort to the Council mailing list detailing why they think the council members should vote for them.
# On or around the first weekday of December if only one person is running then the Chair will announce this to the tei-council mailing list as an acclamation (and after a short period for objections, to the Board and TEI-L). If multiple people are running, then the Council Chair will appoint a "returning officer" who is not a member of the incoming Council (i.e., not a voter and thus at least a somewhat disinterested party). The returning officer will set up an electronic voting system with the names of the candidates. This should be a private election with no one able to determine who has voted for whom. E.g. if using opavote.org this should have the following settings:
## Results only shown at end
## Method: "Plurality/FPTP/SNTV" for 2 candidates, "Instant Runoff Voting" for 3 or more
## a single winner
## Ballot type: "choose one" for 2 candidates, "ranked enhanced" for 3 or more
## candidate order shuffled
# The returning officer should ensure the election runs for at least 4 days, preferably in early December, after announcing it on the tei-council mailing list (and distributing ballots depending on the system).
# The results will be announced publicly on the tei-council mailing list, and Council members given a brief chance to raise any objections with the election before the current Chair informs the Board and announces it more publicly on TEI-L.
# The new Chair assumes the role on 1 January. The current chair steps down on 31 December. The outgoing and incoming chairs should co-ordinate activities between the election and 1 January so as to ensure a smooth transition. (Remembering that the current Chair might be departing off council at the end of that year.) These dates and timescales can of course shift and are not meant to be set in stone.

== Terminology ==

=== What was the War on Free-text-bearing Attribute Values? ===

The War on Free-text-bearing Attribute Values, also known as the War on Free-text-bearing Attributes and the War on Attributes for short, happened because some have felt that if attribute values don't have a datatype, they are more prone to abuse than if they did. So there has been an effort to give datatypes to as many attributes as possible. Some discussion of this with respect to @rend is available here: http://blogs.oucs.ox.ac.uk/jamesc/2011/12/01/rend-and-the-war-on-text-bearing-attributes/

=== What is the "Birnbaum doctrine"? ===

As expressed in [http://www.tei-c.org/Activities/Council/Working/tcw09.xml TCW09: Backward Compatibility and the Maintenance of the Text Encoding Initiative Guidelines], we should avoid breaking backward compatibility and only do so after serious consideration. It does not mean that we cannot break backwards compatibility, just that we've agreed a set of steps to take when we do so. Our deprecation policy supersedes some of this.

=== In what ways will Council break backwards compatibility? ===

For an egregious error, we might actually change a content model immediately. More often, we will survey the community on TEI-L before doing so, and we might [[Practices no longer recommended or now deprecated|deprecate]].

=== What is the "Durand Conundrum"? ===

The "Durand Conundrum" was suggested by David G. Durand concerning the TEI's decision to use the [[ODD | TEI ODD]] meta-schema language rather than just one of the existing schema languages. Given that we decided to use our own language, why use RelaxNG as part of that language for describing content models? Generally, the consensus is that [[ODD | TEI ODD]] gives us greater power and flexibility than any individual schema language can do in that we can model things that those schema languages are currently unable to cope with. TEI ODD gives the ability for a single document to produce both documentation and schema since these are inherently interlinked. It also keeps the TEI honest, in requiring it to use its own system to document schemas. [[ODD | TEI ODD]] does currently have some problems, a few of which are detailed at [[ODD-dev]] and successive revisions of TEI ODD are intended to solve some of these. Increasingly [[ODD#Future_plans:_.22Pure_ODD.22|the work on Pure ODD elements for content models and datatypes]] has cut the gordian knot of this problem.

=== What does "no magic" mean? ===

'Magic' in the sense sometimes used in Council discussion refers to pre-existing or special knowledge required to process something. For example, it was only by 'magic' that a TEI ODD processor would know to add attributes from the att.global attribute class to elements until this was changed to make all element specifications have to explicitly claim membership in this class if they wanted the global attributes. Knowing to add them was 'magic', and in general it is better if any requirements or understood knowledge is explicitly documented. While some 'magic' of understood conventions or processing will always remain in complex technical systems, the Council strives to at very least enable the possibility of documenting the underlying rules when it discovers them. James Cummings has been a fervent proponent of the removal of any understood 'magic' rules from the TEI.

=== What is a "magic token"? ===

This is an value, usually an attribute value, such as that of @key or @rend, which does not follow a standard outside vocabulary but instead is understood in some undocumented way and often used for local processing. It should usually be explained in the teiHeader if possible. Having any processing rely on undocumented magic tokens is generally considered a bad idea. See also [http://en.wikipedia.org/wiki/Magic_cookie Magic Cookie].

=== What is a non-deterministic content model? ===

If you have a content model for <tt><a></tt>:

<code>
b*, c?, b*
</code>

and you have a document with:

<pre>
<a>

</a>
</pre>

then a parser can't tell whether the <tt></tt> matches the first <tt>b*</tt> or the second <tt>b*</tt> in the content model. Thus, the content model itself is called “non-determinstic”. DTDs and W3C XML Schemas reject non-deterministic content models. Thus, if we were to create one in the TEI, validation with DTD and XSD would fail due to errors ''in the schema'', regardless of whether the instance document has an occurence that is non-deterministic or not.

=== What are Janus elements? ===

These are pairs of elements that are in a sense two sides of the same coin, such as orig and reg, corr and sic, abbr and expan.

=== What does it mean to say that elements tessellate? ===

This means that all textual content is included in exactly one instance of an element. For example, once you start using divs (numbered or unnumbered), all text thereafter must be inside of one of the divs: you can't start using p elements that are not wrapped in a div.

In the Guidelines this is sometimes referred to as end-to-end segmentation.

== Meetings ==

=== Where are the minutes of previous meetings? ===

Minutes are [http://www.tei-c.org/Activities/Council/Meetings/index.xml archived on the TEI website]. Interim states of minutes may at times live in this wiki, Google Docs, or elsewhere.

=== How are the teleconferences held? ===

Currently the TEI Council uses the teleconferencing facilities provided by commercial provider since this has proved most cost effective with less problems than other VOIP-based solutions. This has 800/free call numbers for most countries, and low-cost for some. This will be set up by the Council Chair in advance and details posted to the list.

The specific details of what number to dial and what access code is needed will be circulated on the council list shortly before the meeting.

=== What funding is available for Council Activities? And how do I get reimbursed? ===

The TEI funds the participation of the council members in the meetings. Though I don't know of anyone claiming back telephone conferencing costs, I suppose that is possible as well, in most cases the council members' institutions probably swallow that.

If the council has a meeting, then the council members' travel, hotel, etc. will be reimbursed with proper receipts. The TEI reimburses all reasonable expenses in keeping with standard practice at most universities and granting agencies. We cover meals, travel, lodging, and other common daily travel expenses. Airfare should be economy class and direct return, unless otherwise arranged with the Treasurer prior to your trip. (See [http://www.tei-c.org/Board/procedures.xml#body.1_div.8 draft reimbursement policies and procedures].) If you have questions about reimbursement procedures, including what is reimbursable, please email John Unsworth, the TEI treasurer, at john.m.unsworth AT gmail.com.

Use the TEI Travel expense form available here: https://www.tei-c.org/wp-content/uploads/2017/10/TEI_travel_form.pdf '''Expense forms should be submitted within 10 days of the end of the meeting.'''

Council members are not funded to attend the TEI Members' Meeting, however, there has been discussion concerning whether the council should also officially meet here as well.

== How we get work done ==

=== How can I get straight to certain tickets in SourceForge? ===
''''(This is now out of date since we've moved to GitHub... leaving here for a bit for historical interest.)''''
SourceForge divides all tickets into "bugs" and "feature requests". You must browse them separately. You can browse all in a given category from the links at http://tei.sourceforge.net/ .

Before we upgraded to the new Allura system on SourceForge for our tickets, tickets had old, ugly URLs. To get around using these, we set up short URLs maintained by James Cummings and others, which which you could append the attribute ID to the end of the appropriate one of the two URLs where it says 'NUMBER' in order to reach the right ticket:

<nowiki>
http://purl.org/TEI/bug/NUMBER
http://purl.org/TEI/FR/NUMBER
</nowiki>

The new URLs are much more human readable and so those should now be used in preference. Some legacy documents may still use the old PURL URLs. Furthermore, if a legacy document references a ticket number from the old system, you can use one of these PURLs in order to be redirected to the new URL.

=== I have something to say about a GitHub Feature Request or Bug: Should I comment on the ticket or the TEI Council mailing list? ===

There is no hard-and-fast policy on this. The mailing list is a better place for ongoing discussions where people are arguing back and forth during decision making. The GitHub tracker is the appropriate place to record opinions, positions, and decisions for posterity, especially if such would help a) whoever is implementing the decisions recorded in the ticket, b) anyone revisiting this decision later to retrace the thinking. The [http://lists.tei-c.org/pipermail/tei-council/ TEI Council mailing list archives] are public, so if substantial discussion has taken place there (or indeed on TEI-L), this can also be linked to from the ticket.

=== When is discussion on an element or topic "closed" and how do I know? ===

Any topic can be revisited at any point, even in the published guidelines, through posting a feature request on GitHub. Council-specific issues should be raised on the council mailing list, after having reviewed any previous discussion on the topic in the [http://lists.tei-c.org/pipermail/tei-council/ tei-council mailing list archives].

=== How can I find out about every time a ticket is created or commented on? ===

'''FIX-ME: Needs update to github''''
Two options:

* By RSS: Subscribe to an [http://sourceforge.net/export/rss2_keepsake.php?group_id=106328 RSS feed that includes new tickets and comments on existing ones]
* By email:
*#Create a SourceForge user, or log in to an existing account.
*# Make sure you have joined the TEI project.
*# Click the "monitor" button at https://sourceforge.net/tracker/?group_id=106328&source=navbar to receive an email for each change (but what exactly does this include?)

=== How are tickets assigned in GitHub? ===
All members of Council are made part of the Council 'Team on the GitHub TEIC Organisation and meant to take an active role in the development and maintenance of the TEI Guidelines. This means that they have write access to the TEI Guidelines Github Repository, and tickets can be assigned to them in the ticket trackers. They can also update and modify tickets. This means that Council members are free to 'take' tickets which they wish to oversee. Other Council members can also 'give' tickets to each other if they think someone particularly suited to overseeing a particular ticket. (However, usually they should have the Council member's permission to do so.) On a regular basis the Council Chair will assign tickets to Council members, if a ticket gets assigned to them that they don't want to do they should tell the Chair and/or ask other Council members to swap.

=== What does Red, Amber, and Green mean in classifying a ticket? ===

* 'Red' means that the ticket has not been discussed sufficiently and that the answer to it is not necessarily clear. There needs to be more discussion, more examples, use cases, and possibly a clearer proposal about what specifically needs to be done. Or possibly, the ticket does have these things but Council has not yet discussed it or enough Council members seen it for it to warrant an 'Amber' status.

* 'Amber' means that the ticket has been discussed and/or there may be some general consensus on what the correct thing to do is, but necessary components are missing. It may be some examples, use-cases, or prose are missing. Or there is a question of which of several possible solutions is the correct one.

* 'Green' means that the ticket has been discussed, there is general consensus on what the correct thing to do is, and it has been assigned for someone to ensure its implementation.

=== How does a TEI release happen? ===

The process of making a release is documented at http://www.tei-c.org/Activities/Council/Working/tcw22.xml

== Working in GitHub ==

=== How do I edit the TEI Guidelines? ===

Editing the TEI Guidelines is a complex process and the Council has produced a document http://www.tei-c.org/Activities/Council/Working/tcw20.xml covering the logical and physical layout of the Guidelines, stylistic notes, how to make a change to the Guidelines (it requires [[TEI-Council-FAQ#How_do_I_use_GitHub.3F|using subversion]], building a release, and a reference section of useful information. If any information you need isn't in this document, ask on the Council list and get someone to update it!

=== How can I find out about every time a change is made in the TEI GitHub repository? ===
# Go to https://github.com/TEIC/
# Make sure you are logged in and
# go into each repository you are interested in and 'watch' them.

=== How do I use GitHub? ===
The TEI stores its working files in repositories in the [https://github.com/TEIC TEIC GitHub Organization]. See the [http://www.tei-c.org/guidelines/p5/using-the-tei-github-repository/ instructions]. Write access is reserved for those who are on the TEI Council or TEI Contributors teams. Any Council member should be able to add you to the Council team.

=== What should I put in a GitHub commit message? ===

It is beneficial to all those looking at the TEI GitHub repository if commit messages are clear and detailed. This is especially true when trying to revert changes made by yourself or others to solve problems. A good commit message will include:
* a subject line less than 72 characters long (which may be the whole message if no more is needed)
* an explanation to a useful level of detail about what you did
* a mention of why this is being done
* the GitHub issue numbers (or urls) that relate to the change if applicable
* an explanation of whether this change is completing the work described or one step towards doing so.

== TEI website ==

=== I want to add a document to add meeting minutes, reports, or working papers to the TEI-C website. How do I do that? ===

The TEI webmasters -- currently Kevin Hawkins and Nick Homenda -- have access to the CMS behind the TEI website. The site uses a stylesheet to render TEI Lite documents in XHTML, though the CMS can also deliver non-TEI documents. However, for long-term preservation and consistency, use of TEI Lite is encouraged.

You can author a document from scratch or take an existing document as a starting point. To get the XML source of an existing document, simply click "XML View" in the footer of a page on the TEI-C website and choose "save as" in your browser.

The TEI has a longstanding naming convention for files that consists of:

# a short alphabetical abbreviation for a committee (such as "tc" for "Technical Council")
# a one-letter abbreviation for minutes ("m"), reports ("r"), or working papers ("w")
# a two-digit number for the document with a committee series, numbered sequentially (e.g., "tcw01" is the first working paper from the Technical Council, "tcm05" is the fifth minutes from the Technical Council, etc.)

There is no registry of documents, so when creating a new one, you simply name the file appropriately.

Send the file to a webmaster for putting online. If you are hesitant to have the page go live until you have previewed it, you can ask the webmaster to send you a derived HTML version using the stylesheets without publishing that document.

=== How do I get access to the Google Analytics Data for www.tei-c.org? ===

Email the TEI-C webmaster: web@tei-c.org.

== Miscellaneous ==

=== Why do some elements have @type and others do not? ===

The TEI has avoided adding @type globally to elements because its availability is thought to invite tag or attribute abuse. In order for a request to add @type to an element to be considered for prolonged discussion and argument the TEI Technical Council has a standing principle that an element should be both repeatable and have obvious different classifications that apply to it. If such a request is approved then the preferred method is to make the element a member of the att.typed class (because if you can have @type, you can also have sub-types and thus need @subtype). If a closed or suggested value list, or different description is needed, this should then be provided as a local modification to the attributes inherited from att.typed.

== I have a question! ==

Then add it just above this one or email someone on the council or the council list reminding them of the existence of this wiki page when you ask your question.

[[Category:Council]]

TEI-Council-FAQ

2019-10-08T13:50:48Z

Hcayless: /* Working in GitHub */

So you have some questions about how the [[Council|TEI Technical Council]] works? This page has been set up to answer questions that new council members (or other curious parties) may have.

== Overview ==

=== How does the Council do its work? ===

By every means possible. These include regular telephone conferences, endless streams of email, widely circulated discussion documents, private caucussing, public debate in other contexts such as TEI-L, and private gossip. Formally speaking, the Council meets face to face once a year (at least), and many more times than that virtually.

=== And what work does it do? ===

You should probably review the recent official work of the Council by reading the last few sets of minutes: http://www.tei-c.org/Council/ has an index page which links to them all (when we remember to update it). The minutes record topics discussed and responsibilities allocated at the Council level. Of course many Council members are also active in subgroups (formal or informal) of the Council or SIGs, which may be documented elsewhere as well.

Generally, things in Council work like this:

# A bug report or feature request is reported by anyone at [https://github.com/TEIC/ GitHub] for the [https://github.com/TEIC/TEI/issues Guidelines] or [https://github.com/TEIC/Stylesheets/issues Stylesheets].
# Sometimes others notice the ticket and comment on it.
# Sometimes a Council member may make an executive decision on the ticket. If it's a corrigible error or bug, we can just fix it in the appropriate ODD file(s) (also in GitHub). If it is not a real issue, sometimes the ticket will just be closed. If you do not have developer access on GitHub you'll to ask to be added to the Council team there. Otherwise, it's discussed either by email on the Council mailing list or at a Council meeting (conference call or in-person meeting). Comments are recorded in the ticket reflecting the decision reached, and changes are made in GitHub by a member of the Council sometime thereafter.
# The change shows up on tei-c.org after the next TEI "release", which happens about two or three times a year.

However, Council does sometimes consider lengthy proposals circulated to Council outside of GitHub and vote on them as packages, with the changes grouped together in a sensible way so they can be considered in smaller packages, or with the changes listed individually.

=== And what is its scope? ===

The Council's primary responsibility is to act as technical watchdog for the intellectual content of the TEI Guidelines. That is to say: it has the final say in just about every aspect of the TEI encoding scheme -- what elements exist in it, what they are called, how they should be used.

=== How do I join the TEI Council mailing list? ===

We have had the practice on the Council so far that elected members get added immediately to the list (and to the telecon, if there is one), with every right to participate, while outgoing members stay on until the end of their term. To join or discuss any problems using the list contact the [mailto:tei-council-owner@lists.tei-c.org TEI Council mailing list owner], currently this is Kevin Hawkins (North Texas) and Nick Homenda (Indiana). There is also a joint Board/Council mailing list to which you should be added as well.

=== Why are some people on the Council email list or attending Council meetings even though they are not on the list of elected members? ===

In addition to the members of the Council, the chair of the TEI Technical Council may invite others not elected to the Council to meetings (e.g. to speak to a particular issue). Historically the Council often invited a representative of the Board to the Council mailing list and meetings. The TEI-C Webmaster (currently Kevin Hawkins) and Assistant Webmaster (Nick Homenda) are also on the mailing lists.

=== What are the various job roles on the TEI Council? ===

==== TEI Technical Council Member ====
A TEI Technical Council Member is expected to participate in all aspects of Council work. This means that they should learn how the TEI infrastructure is organised and [http://www.tei-c.org/Activities/Council/Working/tcw20.xml how to edit the TEI Guidelines], asking on the Council list any questions they might have. They will be expected to come to face-to-face ("f2f") meetings (often two per year) and participate in a couple other teleconferences per year. They will be assigned (or take) feature requests/bugs on [https://github.com/TEIC the TEI Consortium's GitHub site], for which they will be in charge of encouraging discussion, reporting on the issue to Council, and eventually implementing (or ensuring implementation) of the resulting decision. A TEI Technical Council Member is expected to participate in the maintenance and development of the TEI Guidelines and related outputs. Some elected TEI Council members focus more on particular aspects of the infrastructure or stylesheets as part of the contribution to the Council. Council members should always act to represent what they believe are the opinions and best interest of the community that has elected them.

==== TEI Technical Council Chair ====
The TEI Technical Council Chair's role is to administrate and facilitate the work of the TEI Technical Council. If all of the Council are the elected servants of the community, then the Council Chair is the servant of the servants of the TEI (''Servus servorum TEI''). The duties of the Technical Council Chair include (in no particular order):
* ensuring the delivery and maintenance of the Guidelines
* arranging for Council members to actively participate in Council activities
* arranging and chairing the face-to-face meetings (in conjunction with the local organiser)
* arranging and chairing the teleconferences
* creating agendas for those meetings, and ensuring minutes are written and posted of them
* assigning tickets in [http://github.com/TEIC/ the TEIC Github organization]
* acting as SIG coordinator
* liaising for and reporting on Council activities at all Board meetings
* reflecting Council wishes in Board discussions
* acting as a public point of contact and responding to technical enquiries (messages to council@tei-c.org are forwarded to the Council Chair)
* announcing new releases of the Guidelines on the TEI-L mailing list
* ensuring the smooth running of the TEI Technical Council

The TEI Technical Council Chair is also a member of the Council, so has all the duties and obligations of being a council member as well.

==== Release Technician ====
The TEI Guidelines release process (see [http://www.tei-c.org/Activities/Council/Working/tcw22.xml tcw22: Building a TEI Release]) involves a single individual responsible for 'pushing the button' and completing the steps required to make a TEI Guidelines release live. This is not a standing position; instead, the responsibility rotates for every release in order to demystify the release process and spread the expertise beyond Oxford staff. Although we have documented the work in quite a detailed manner, it is a non-trivial process and involves a fair degree of work. A release technician is usually required to set aside a whole day for the release process since history teaches us that often the entire process needs to be re-run to correct last-minute errors.

==== TEI-C Webmaster and Assistant Webmaster ====

The TEI-C Webmaster and Assistant Webmaster are not officially part of the Council but may be added to the mailing lists at the discretion of the Council Chair. They are responsible for the smooth running of the TEI-C Website.

=== How is the TEI Technical Council Chair elected? ===

The [http://www.tei-c.org/About/bylaws.xml#body.1_div.3_div.3 Bylaws of the TEI-C] say that:
<blockquote>
The Chair of the Technical Council shall be elected by the voting Members of the TEI-C Technical Council from its membership and shall serve as the chief technical officer of the Consortium. If no Technical Council Member is able or willing to assume the chair, the Technical Council may request the Board of Directors to second one of its elected members to the role, or it may nominate a non-elected individual.
</blockquote>
This leaves it intentionally vague as to the precise process the TEI Technical Council will follow. For now there is vague consensus that they will do something like the following. Note that timeframes below are not intended to be rigid or precise, but rather to be suggestive.
# The new Technical Council Members will be added to the tei-council (and tei-board-council) mailing lists shortly after the members' meeting. Up until around the last last Friday in November those who are Council members for next year will consider whether they want to run to be Chair of the TEI Technical Council. The current Chair will facilitate this process by answering any questions about the post. Before that date those intending to stand should send a statement of some sort to the Council mailing list detailing why they think the council members should vote for them.
# On or around the first weekday of December if only one person is running then the Chair will announce this to the tei-council mailing list as an acclamation (and after a short period for objections, to the Board and TEI-L). If multiple people are running, then the Council Chair will appoint a "returning officer" who is not a member of the incoming Council (i.e., not a voter and thus at least a somewhat disinterested party). The returning officer will set up an electronic voting system with the names of the candidates. This should be a private election with no one able to determine who has voted for whom. E.g. if using opavote.org this should have the following settings:
## Results only shown at end
## Method: "Plurality/FPTP/SNTV" for 2 candidates, "Instant Runoff Voting" for 3 or more
## a single winner
## Ballot type: "choose one" for 2 candidates, "ranked enhanced" for 3 or more
## candidate order shuffled
# The returning officer should ensure the election runs for at least 4 days, preferably in early December, after announcing it on the tei-council mailing list (and distributing ballots depending on the system).
# The results will be announced publicly on the tei-council mailing list, and Council members given a brief chance to raise any objections with the election before the current Chair informs the Board and announces it more publicly on TEI-L.
# The new Chair assumes the role on 1 January. The current chair steps down on 31 December. The outgoing and incoming chairs should co-ordinate activities between the election and 1 January so as to ensure a smooth transition. (Remembering that the current Chair might be departing off council at the end of that year.) These dates and timescales can of course shift and are not meant to be set in stone.

== Terminology ==

=== What was the War on Free-text-bearing Attribute Values? ===

The War on Free-text-bearing Attribute Values, also known as the War on Free-text-bearing Attributes and the War on Attributes for short, happened because some have felt that if attribute values don't have a datatype, they are more prone to abuse than if they did. So there has been an effort to give datatypes to as many attributes as possible. Some discussion of this with respect to @rend is available here: http://blogs.oucs.ox.ac.uk/jamesc/2011/12/01/rend-and-the-war-on-text-bearing-attributes/

=== What is the "Birnbaum doctrine"? ===

As expressed in [http://www.tei-c.org/Activities/Council/Working/tcw09.xml TCW09: Backward Compatibility and the Maintenance of the Text Encoding Initiative Guidelines], we should avoid breaking backward compatibility and only do so after serious consideration. It does not mean that we cannot break backwards compatibility, just that we've agreed a set of steps to take when we do so. Our deprecation policy supersedes some of this.

=== In what ways will Council break backwards compatibility? ===

For an egregious error, we might actually change a content model immediately. More often, we will survey the community on TEI-L before doing so, and we might [[Practices no longer recommended or now deprecated|deprecate]].

=== What is the "Durand Conundrum"? ===

The "Durand Conundrum" was suggested by David G. Durand concerning the TEI's decision to use the [[ODD | TEI ODD]] meta-schema language rather than just one of the existing schema languages. Given that we decided to use our own language, why use RelaxNG as part of that language for describing content models? Generally, the consensus is that [[ODD | TEI ODD]] gives us greater power and flexibility than any individual schema language can do in that we can model things that those schema languages are currently unable to cope with. TEI ODD gives the ability for a single document to produce both documentation and schema since these are inherently interlinked. It also keeps the TEI honest, in requiring it to use its own system to document schemas. [[ODD | TEI ODD]] does currently have some problems, a few of which are detailed at [[ODD-dev]] and successive revisions of TEI ODD are intended to solve some of these. Increasingly [[ODD#Future_plans:_.22Pure_ODD.22|the work on Pure ODD elements for content models and datatypes]] has cut the gordian knot of this problem.

=== What does "no magic" mean? ===

'Magic' in the sense sometimes used in Council discussion refers to pre-existing or special knowledge required to process something. For example, it was only by 'magic' that a TEI ODD processor would know to add attributes from the att.global attribute class to elements until this was changed to make all element specifications have to explicitly claim membership in this class if they wanted the global attributes. Knowing to add them was 'magic', and in general it is better if any requirements or understood knowledge is explicitly documented. While some 'magic' of understood conventions or processing will always remain in complex technical systems, the Council strives to at very least enable the possibility of documenting the underlying rules when it discovers them. James Cummings has been a fervent proponent of the removal of any understood 'magic' rules from the TEI.

=== What is a "magic token"? ===

This is an value, usually an attribute value, such as that of @key or @rend, which does not follow a standard outside vocabulary but instead is understood in some undocumented way and often used for local processing. It should usually be explained in the teiHeader if possible. Having any processing rely on undocumented magic tokens is generally considered a bad idea. See also [http://en.wikipedia.org/wiki/Magic_cookie Magic Cookie].

=== What is a non-deterministic content model? ===

If you have a content model for <tt><a></tt>:

<code>
b*, c?, b*
</code>

and you have a document with:

<pre>
<a>

</a>
</pre>

then a parser can't tell whether the <tt></tt> matches the first <tt>b*</tt> or the second <tt>b*</tt> in the content model. Thus, the content model itself is called “non-determinstic”. DTDs and W3C XML Schemas reject non-deterministic content models. Thus, if we were to create one in the TEI, validation with DTD and XSD would fail due to errors ''in the schema'', regardless of whether the instance document has an occurence that is non-deterministic or not.

=== What are Janus elements? ===

These are pairs of elements that are in a sense two sides of the same coin, such as orig and reg, corr and sic, abbr and expan.

=== What does it mean to say that elements tessellate? ===

This means that all textual content is included in exactly one instance of an element. For example, once you start using divs (numbered or unnumbered), all text thereafter must be inside of one of the divs: you can't start using p elements that are not wrapped in a div.

In the Guidelines this is sometimes referred to as end-to-end segmentation.

== Meetings ==

=== Where are the minutes of previous meetings? ===

Minutes are [http://www.tei-c.org/Activities/Council/Meetings/index.xml archived on the TEI website]. Interim states of minutes may at times live in this wiki, Google Docs, or elsewhere.

=== How are the teleconferences held? ===

Currently the TEI Council uses the teleconferencing facilities provided by commercial provider since this has proved most cost effective with less problems than other VOIP-based solutions. This has 800/free call numbers for most countries, and low-cost for some. This will be set up by the Council Chair in advance and details posted to the list.

The specific details of what number to dial and what access code is needed will be circulated on the council list shortly before the meeting.

=== What funding is available for Council Activities? And how do I get reimbursed? ===

The TEI funds the participation of the council members in the meetings. Though I don't know of anyone claiming back telephone conferencing costs, I suppose that is possible as well, in most cases the council members' institutions probably swallow that.

If the council has a meeting, then the council members' travel, hotel, etc. will be reimbursed with proper receipts. The TEI reimburses all reasonable expenses in keeping with standard practice at most universities and granting agencies. We cover meals, travel, lodging, and other common daily travel expenses. Airfare should be economy class and direct return, unless otherwise arranged with the Treasurer prior to your trip. (See [http://www.tei-c.org/Board/procedures.xml#body.1_div.8 draft reimbursement policies and procedures].) If you have questions about reimbursement procedures, including what is reimbursable, please email John Unsworth, the TEI treasurer, at john.m.unsworth AT gmail.com.

Use the TEI Travel expense form available here: https://www.tei-c.org/wp-content/uploads/2017/10/TEI_travel_form.pdf '''Expense forms should be submitted within 10 days of the end of the meeting.'''

Council members are not funded to attend the TEI Members' Meeting, however, there has been discussion concerning whether the council should also officially meet here as well.

== How we get work done ==

=== How can I get straight to certain tickets in SourceForge? ===
''''(This is now out of date since we've moved to GitHub... leaving here for a bit for historical interest.)''''
SourceForge divides all tickets into "bugs" and "feature requests". You must browse them separately. You can browse all in a given category from the links at http://tei.sourceforge.net/ .

Before we upgraded to the new Allura system on SourceForge for our tickets, tickets had old, ugly URLs. To get around using these, we set up short URLs maintained by James Cummings and others, which which you could append the attribute ID to the end of the appropriate one of the two URLs where it says 'NUMBER' in order to reach the right ticket:

<nowiki>
http://purl.org/TEI/bug/NUMBER
http://purl.org/TEI/FR/NUMBER
</nowiki>

The new URLs are much more human readable and so those should now be used in preference. Some legacy documents may still use the old PURL URLs. Furthermore, if a legacy document references a ticket number from the old system, you can use one of these PURLs in order to be redirected to the new URL.

=== I have something to say about a GitHub Feature Request or Bug: Should I comment on the ticket or the TEI Council mailing list? ===

There is no hard-and-fast policy on this. The mailing list is a better place for ongoing discussions where people are arguing back and forth during decision making. The GitHub tracker is the appropriate place to record opinions, positions, and decisions for posterity, especially if such would help a) whoever is implementing the decisions recorded in the ticket, b) anyone revisiting this decision later to retrace the thinking. The [http://lists.tei-c.org/pipermail/tei-council/ TEI Council mailing list archives] are public, so if substantial discussion has taken place there (or indeed on TEI-L), this can also be linked to from the ticket.

=== When is discussion on an element or topic "closed" and how do I know? ===

Any topic can be revisited at any point, even in the published guidelines, through posting a feature request on GitHub. Council-specific issues should be raised on the council mailing list, after having reviewed any previous discussion on the topic in the [http://lists.tei-c.org/pipermail/tei-council/ tei-council mailing list archives].

=== How can I find out about every time a ticket is created or commented on? ===

'''FIX-ME: Needs update to github''''
Two options:

* By RSS: Subscribe to an [http://sourceforge.net/export/rss2_keepsake.php?group_id=106328 RSS feed that includes new tickets and comments on existing ones]
* By email:
*#Create a SourceForge user, or log in to an existing account.
*# Make sure you have joined the TEI project.
*# Click the "monitor" button at https://sourceforge.net/tracker/?group_id=106328&source=navbar to receive an email for each change (but what exactly does this include?)

=== How are tickets assigned in GitHub? ===
All members of Council are made part of the Council 'Team on the GitHub TEIC Organisation and meant to take an active role in the development and maintenance of the TEI Guidelines. This means that they have write access to the TEI Guidelines Github Repository, and tickets can be assigned to them in the ticket trackers. They can also update and modify tickets. This means that Council members are free to 'take' tickets which they wish to oversee. Other Council members can also 'give' tickets to each other if they think someone particularly suited to overseeing a particular ticket. (However, usually they should have the Council member's permission to do so.) On a regular basis the Council Chair will assign tickets to Council members, if a ticket gets assigned to them that they don't want to do they should tell the Chair and/or ask other Council members to swap.

=== What does Red, Amber, and Green mean in classifying a ticket? ===

* 'Red' means that the ticket has not been discussed sufficiently and that the answer to it is not necessarily clear. There needs to be more discussion, more examples, use cases, and possibly a clearer proposal about what specifically needs to be done. Or possibly, the ticket does have these things but Council has not yet discussed it or enough Council members seen it for it to warrant an 'Amber' status.

* 'Amber' means that the ticket has been discussed and/or there may be some general consensus on what the correct thing to do is, but necessary components are missing. It may be some examples, use-cases, or prose are missing. Or there is a question of which of several possible solutions is the correct one.

* 'Green' means that the ticket has been discussed, there is general consensus on what the correct thing to do is, and it has been assigned for someone to ensure its implementation.

=== How does a TEI release happen? ===

The process of making a release is documented at http://www.tei-c.org/Activities/Council/Working/tcw22.xml

== Working in GitHub ==

=== How do I edit the TEI Guidelines? ===

Editing the TEI Guidelines is a complex process and the Council has produced a document http://www.tei-c.org/Activities/Council/Working/tcw20.xml covering the logical and physical layout of the Guidelines, stylistic notes, how to make a change to the Guidelines (it requires [[TEI-Council-FAQ#How_do_I_use_GitHub.3F|using subversion]], building a release, and a reference section of useful information. If any information you need isn't in this document, ask on the Council list and get someone to update it!

=== How can I find out about every time a change is made in the TEI GitHub repository? ===
# Go to https://github.com/TEIC/
# Make sure you are logged in and
# go into each repository you are interested in and 'watch' them.

=== How do I use GitHub? ===
''''FIX-ME: NEeds to be updated to github'''
The TEI stores its working files in the TEI GitHub Repositories, with read access to anyone who wishes. See the [http://www.tei-c.org/guidelines/p5/using-the-tei-github-repository/ instructions]. Write access is reserved for those who are on the TEI Council or TEI Contributors teams. Any Council member should be able to add you to the Council team.

=== What should I put in a GitHub commit message? ===

It is beneficial to all those looking at the TEI GitHub repository if commit messages are clear and detailed. This is especially true when trying to revert changes made by yourself or others to solve problems. A good commit message will include:
* a subject line less than 72 characters long (which may be the whole message if no more is needed)
* an explanation to a useful level of detail about what you did
* a mention of why this is being done
* the GitHub issue numbers (or urls) that relate to the change if applicable
* an explanation of whether this change is completing the work described or one step towards doing so.

== TEI website ==

=== I want to add a document to add meeting minutes, reports, or working papers to the TEI-C website. How do I do that? ===

The TEI webmasters -- currently Kevin Hawkins and Nick Homenda -- have access to the CMS behind the TEI website. The site uses a stylesheet to render TEI Lite documents in XHTML, though the CMS can also deliver non-TEI documents. However, for long-term preservation and consistency, use of TEI Lite is encouraged.

You can author a document from scratch or take an existing document as a starting point. To get the XML source of an existing document, simply click "XML View" in the footer of a page on the TEI-C website and choose "save as" in your browser.

The TEI has a longstanding naming convention for files that consists of:

# a short alphabetical abbreviation for a committee (such as "tc" for "Technical Council")
# a one-letter abbreviation for minutes ("m"), reports ("r"), or working papers ("w")
# a two-digit number for the document with a committee series, numbered sequentially (e.g., "tcw01" is the first working paper from the Technical Council, "tcm05" is the fifth minutes from the Technical Council, etc.)

There is no registry of documents, so when creating a new one, you simply name the file appropriately.

Send the file to a webmaster for putting online. If you are hesitant to have the page go live until you have previewed it, you can ask the webmaster to send you a derived HTML version using the stylesheets without publishing that document.

=== How do I get access to the Google Analytics Data for www.tei-c.org? ===

Email the TEI-C webmaster: web@tei-c.org.

== Miscellaneous ==

=== Why do some elements have @type and others do not? ===

The TEI has avoided adding @type globally to elements because its availability is thought to invite tag or attribute abuse. In order for a request to add @type to an element to be considered for prolonged discussion and argument the TEI Technical Council has a standing principle that an element should be both repeatable and have obvious different classifications that apply to it. If such a request is approved then the preferred method is to make the element a member of the att.typed class (because if you can have @type, you can also have sub-types and thus need @subtype). If a closed or suggested value list, or different description is needed, this should then be provided as a local modification to the attributes inherited from att.typed.

== I have a question! ==

Then add it just above this one or email someone on the council or the council list reminding them of the existence of this wiki page when you ask your question.

[[Category:Council]]

Travel Reimbursement Procedures for Council and Board Members

2019-10-01T13:36:16Z

Hcayless: /* Reimbursement Procedure */

=Reimbursement Policies and Procedures=

* [http://www.tei-c.org/Admin/TEI_travel_form.pdf TEI-C Travel Reimbursement Form]

----

The TEI Consortium (TEI-C) is a volunteer-run organization that represents a community that continues to grow in numbers and geographic representation. In order to function smoothly and continue its outreach, the TEI-C compensates individuals for travel for TEI-related business. For example, the TEI-C will reimburse keynotes or other invited speakers to annual conferences and Council and Board members for face-to-face meetings. Travel reimbursement requests outside of the norm are at the discretion of the TEI-C Board of Directors.

The TEI-C will reimburse Board-approved travel for '''reasonable expenses''', which includes economy airfare, conference-designated lodging (or cheaper!), and per diem designated by the U.S. Department of State [Domestic https://www.gsa.gov/travel/plan-book/per-diem-rates] and [Foreign https://aoprals.state.gov/web920/per_diem.asp] Per Diem Rates. Expenses incurred beyond what is reasonable will be evaluated for additional compensation on a case by case basis.

The TEI-C appreciates travel expenses covered by an individual's institution as part of the institutions's overall commitment to the TEI. Likewise, the TEI-C appreciates individuals who offset or cover in-full their own travel expenses for TEI-related business. We encourage an individual's ability to subsidize or cover completely the costs associated with TEI-C-related business travel.

In broad terms, its reimbursement policies are in keeping with those common practice in the U.S. University and Public Sector. Questions about these policies or concerning expenses not covered here should be directed to the Treasurer. While exceptions and clarifications are possible, these should normally be requested before the expense is incurred.

'''Receipts for all travel-related transactions with the exceptions of food-related and incidentals receipts must be submitted for reimbursement.''' See explanation of meals and incidentals breakdown for the current calendar year at: https://www.gsa.gov/travel/plan-book/per-diem-rates.

Specific guidelines for allowable expenses are described below.

==Transportation to TEI-C Events and Activities==

Airfare should be by the cheapest direct route and economy class or equivalent. Ground transportation should be by cheapest direct route and economy/second class (if applicable) or equivalent. Transportation involving detours, stop-overs, or travel to additional destinations may be eligible for full or partial reimbursement. Individuals considering such travel should make arrangements with the Treasurer in advance.

The TEI-C will reimburse expenses related to traveling to/from an airport including airport parking and transportation to/from airports. We ask that you find the most economical form of long-term airport parking as well as economical transportation to/from airports, which may include sharing a taxi with colleagues. The TEI-C will also reimburse transportation expenses from lodging to meeting locations (over $20). Most in-town commuting will be covered by the "Incidental Expenses" portion of the per diem (see below). We ask that you find the most economical form of in-town commuting, which may include multi-day transit passes or taxi-sharing.

==Lodging==

The TEI-C will reimburse eligible individuals for reasonable actual hotel and lodging costs for stays necessitated by TEI meetings. In addition of lodging costs for a single individual, these costs may include internet access '''BUT NOT''' entertainment, newspapers, the use of a mini-bar, or meals (meals are reimbursed on a per diem basis). No other charges are permitted without prior arrangement. Such claims must be accompanied by receipts.

In reimbursing for such costs the TEI-C will '''pay for a maximum of one additional night before and/or after the event or activity'''. Individuals may exceed this maximum of the additional night(s) can be justified as a way of reducing the overall cost of the trip (e.g., when a Saturday overnight reduces the airfare more than the cost of the added hotel stay). Individuals considering such an arrangement should contact the Treasurer before booking their stay whenever possible.

Individuals sharing a room with friends or family not paticipating in TEI-C business should make separate arrangements with the Treasurer if the additional occupant results in extra costs being levied by the hotel. There is no need to make separate arrangements if the hotel in question charges by the room rather than number of occupants.

==Meals and Incidental Expenses (Per Diem)==

The TEI reimburses eligible individuals for meals and incidental expenses on a per diem basis. These per diem rates usually are calculated from U.S. Government rates using the following formula:

===Travel outside the U.S.===
For travel outside the continental U.S., the Meals and Incidentals per diem is designated by the [https://aoprals.state.gov/web920/per_diem.asp relevant U.S. State Department rate].

===Travel within the U.S ===

For travel within the continental U.S., the Meals and Incidentals per diem is designated by the [https://www.gsa.gov/travel/plan-book/per-diem-rates relevant U.S. General Service Administration rate].

The Board reserves the right to set its per diem rates using a different formula provided advance notice is given to the traveller.

===Eligible Per Diem Expenses===

The per diem rates are intended to cover actual meals and incidental daily living expenses (excluding lodging) for eligible individuals while they are travelling on TEI business. Per diems should not be claimed for expenses that are paid for by somebody else, eligible for reimbursement from other sources, or that occur before or after the travel takes place. '''No receipts are required for expenses claimed as part of a per diem.'''

The following are some examples of expenses covered by the Meals and Incidental per diem. The list is not intended to be exhaustive. If in doubt, please contact the Treasurer.

====Meals====
The per diem is intended to cover all meals paid for by individuals on their own behalf. No receipts are required in such cases. Reimbursement for group meals organised in advance by the TEI or local hosts or for costs incurred in paying for meals of guests of the TEI should be requested separately and require receipts. Individuals participating (but not paying for) such meals should not also claim the equivalent meal allowance. Informal groups dining together should ask for separate checks or otherwise settle the bill amongst themselves before claiming their per diems as individuals. Individuals will not normally be reimbursed for group meals not arranged in advance.

====Incidental Expenses====
The per diem is also intended to cover incidental and minor expenses such as tips, in-town taxi and public transit fares, and the like. Reimbursement for ground transportation above $20 should be requested separately (with receipts).

==Reimbursement Procedure==

In order to be reimbursed a traveler should fill out a [https://tei-c.org/tei_travel_form/ TEI-C Travel Reimbursement Form] and send it to the treasurer at the address indicated on the form '''within 1 month of travel'''. Hotel, airfare, and other significant transportation related receipts should be sent with the form. Receipts for meals and incidentals should not be included.

[[Category:Board]]

Editor for teaching TEI - features

2016-07-09T10:13:30Z

Hcayless: /* Basic required features */

[[Category:Editing tools]]
This is an attempt at listing the minimal set of features that a TEI editor '''used for teaching purposes''' should have.

=== Basic required features ===
* multiplatform
* validation with Relax NG based on the xml-model PI in the document
* contextual suggestions (following the schema)
* XSLT 2 transformation (Saxon HE? that would offer XQuery as well)
* easy to use
* free
* syntax highlighting for XML (that naturally includes XSLT)

=== Good-to-have but not mandatory ===
* xPath query
* Inline documentation (i.e. the little pop-ups with the definition of the element)
* pre-set templates (example?)
* syntax highlighting for XQuery

=== Features we can live without in a "teaching editor" ===
* No XSLT 3 (as a consequence of the fact that no commercial tool such as Saxon PE/EE could be used in such an editor)
* No need for XSLT or XQuery debuggers
* no need for database connectivity
* no need for a built-in SVN (etc.) client
* no need for a Tree Editor such as the one offered by oXygen
* no need for Compare Files/Directories tools
* no need for big-file editor or big-file support in general
* no need for syntax highlighting and editing support for some file types which are not XML-based (JavaScript, CSS, JSON, etc.).

=== Notes ===
The impetus for establishing the above came from a sub-thread on the [[TEI-L]] list bulleted by the following messages: [https://listserv.brown.edu/archives/cgi-bin/wa?A2=tei-l;fcdcab72.1607], [https://listserv.brown.edu/archives/cgi-bin/wa?A2=tei-l;af28895d.1607], [https://listserv.brown.edu/archives/cgi-bin/wa?A2=tei-l;83b06464.1607]. The idea is to see whether the community can agree on a single feature set that a dumbed-down commercial editor can implement is a "student version" with an appropriate license.
Or, as Martin Holmes puts it, we want to "arrive at something which would be utterly useless for the likes of me, and quite frustrating for serious users, but perfectly functional for teaching introductory XML encoding classes over a few months."

Council

2015-07-27T13:45:05Z

Hcayless: /* Meetings */

The TEI Technical Council, often referred to as 'TEI Council' or 'Council', is the elected body that is responsible for maintaining and implementing the TEI Guidelines. See the [http://www.tei-c.org/Activities/Council/ Council section of the TEI-C website] for archived documents, and [[TEI-Council-FAQ]] for a Council FAQ. The TEI Council also uses this page to store some of its draft agendas and creates pages in the [[:Category: Council|category reserved for use by TEI Council]].

== Meetings ==

See the [[Council-Meeting-Checklist|checklist for organizing a face-to-face meeting]].

{| border="1"
! Meeting date and place
! Agenda
! Minutes
! Action items
|-
|2015-07-28 Teleconference
|[[Council Agenda 2015-07]]
|
|
|-
|2015-06-29 Teleconference
|[[Council Agenda 2015-06]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm70.xml final minutes]
|(in minutes)
|-
|2015-05/27/28/29 Face to face in Ann Arbor, MI, USA
|[[Council Agenda 2015-05]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm69.xml final minutes]
|(in minutes)
|-
|2015-04-24 Teleconference
|[[Council Agenda 2015-04]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm68.xml final minutes]
|(in minutes)
|-
|2015-03-27 Teleconference
|[[Council Agenda 2015-03]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm67.xml final minutes]
|(in minutes)
|-
|2015-02-27 Teleconference
|[[Council agenda 2015-02]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm66.xml final minutes]
|(in minutes)
|-
|2015-01-30 Teleconference
|[[Council agenda 2015-01]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm65.xml final minutes]
|(in minutes)
|-
|2014-12-05 Teleconference
|[[Council agenda 2014-12]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm64.xml final minutes]
|(in minutes)
|-
|2014-11-17/18/19 Face to Face in Durham, NC, USA
|[[Council agenda 2014-11]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm63.xml final minutes]
|(in minutes)
|-
|2014-10-03 Teleconference
|[[Council agenda 2014-10]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm62.xml final minutes]
|(in minutes)
|-
|2014-08-01 Teleconference
|[[Council agenda 2014-08]]
||[http://www.tei-c.org/Activities/Council/Meetings/tcm61.xml final minutes]
|(in minutes)
|-
|2014-06-30/07-02 Face to Face in Oxford
|[[Council agenda 2014-06]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm60.xml final minutes]
| (in minutes)
|-
|2014-05-30 Teleconference
|[[Council agenda 2014-05]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm59.xml final minutes]
| (in minutes)
|-
|2014-03-07 Teleconference
|[[Council agenda 2014-03]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm58.xml final minutes]
| (in minutes)
|-
|2014-01-10 Teleconference
|[[Council agenda 2014-01]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm57.xml final minutes]
|
|-
|2013-11-11 to 2013-11-13 face-to-face Oxford
|[[Council agenda 2013-11]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm56.xml final minutes]
|[[Oxford2013-Actions2]]
|-
|2013-10-21 Teleconference
|[[Council agenda 2013-10]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm55.xml final minutes]
|
|-
|2013-04-11 to 2013-04-13 face-to-face Providence
|[[Council agenda 2013-04]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm54.xml final minutes]
|[[Council actions 2013-04]]
|-
| 2012-12-13 teleconference
| [[Council agenda 2012-12]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm53.xml final minutes]
|
|-
| 2012-09-19 to 2012-09-21 face-to-face meeting Oxford
| [[Council agenda 2012-09]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm52.xml final minutes]
| [[Oxford2012-Actions]]
|-
| 2012-08-09 teleconference
| [[Council agenda 2012-08]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm51.xml final minutes]
|
|-
| 2012-04-15 to 2012-04-18 face-to-face meeting Ann Arbor
| [[Council agenda 2012-04]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm50.xml final minutes]
| [[AnnArbor2012-Actions]]
|-
| 2012-02-28 Teleconference
| [[Council agenda 2012-02]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm49.xml final minutes]
|
|-
| 2011-11-07 to 2011-11-09 face-to-face meeting Paris
| [[Council agenda 2011-11]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm48.xml final minutes]
|
|-
| 2011-08-17 teleconference
|
| [http://www.tei-c.org/Activities/Council/Meetings/tcm47.xml final minutes]
|
|-
| 2011-04-11 to 2011-04-13 face-to-face meeting Chicago
| [[Council agenda 2011-04]]
| [[Council notes 2011-04]], [http://www.tei-c.org/Activities/Council/Meetings/tcm46.xml final minutes]
|
|-
| 2010-10 feature request assignments
| colspan="3" align="center" | [[Council FR assignments]]
|-
| 2010-04-28 to 2010-04-30 face-to-face meeting Dublin
| [[Council agenda 2010-04]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm45.xml final minutes]
|
|-
| 2010-02-08 teleconference
|
| [http://www.tei-c.org/Activities/Council/Meetings/tcm44.xml final minutes]
|
|-
| 2009-12-07 teleconference
|
| [http://www.tei-c.org/Activities/Council/Meetings/tcm43.xml final minutes]
|
|-
| 2009-10-13 teleconference
| [[Council agenda 2009-10]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm42.xml final minutes]
|
|-
| 2009-04-01 to 2009-04-03 face-to-face meeting Lyon
| [[Council 2009-04]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm41.xml final minutes]
|
|-
| 2008-10-07 teleconference
| [[Council agenda 2008-10]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm40.xml final minutes]
|
|-
| colspan="4" align="center" | For minutes of previous meetings, see [http://www.tei-c.org/Activities/Council/Meetings/ minutes on TEI-C website]
|}

== Workgroups ==

A [http://www.tei-c.org/Activities/Workgroups/index.xml full list is on the TEI-C website] and the following wiki pages:

* [[Ad-hoc committee on encoding of bibliographic citations]]
* [[Text Directionality Workgroup]]

== Old notes ==

=== Item for further consideration ===
* Stable URIs to discrete bits of the guidelines

=== Issues for next F2F ===

* Discussion on ODD and its evolution--[[User:Romary|Romary]] 02:34, 9 September 2008 (EDT)

cf. @usage in elementSpec

ODD modifing an ODD (ODD architecture)

Namespaces

* Evolution of Roma

Proposal (SR): rewriting Roma almost entirely in Javascript, interacting with web services to deliver TEI and to generate outputs. The Javascript would grab a copy of TEI (cut down) from a chosen server, and load it into memory. Then it would use that to help you build your ODD. when you were done, it would send the ODD document to a web service whose job is to return a schema or documentation back to the browsers. So Roma would be a Javascript ODD editor, not needing server support beyond a simple Apache, but closely coupled to a pair of generic web services. The generator web service would be identical code to the Vesta desktop

Additional functionalities needed (PB):

- adding copy element functionality,

- supporting the creation/manipulation of content models (instead of the user having to write the models),

- support/help in creating schematron constraints?

- TEI schema validation service (cf. also ISO project)

* should the TEI-C we produce a general purpose online service which can validate and process documents (cf. ISO work)

=== Highlights to be brought to the TEI MM 2008 ===

=== Topics (could be moved up to one F2F or Telco meeting ===

* Stable reference to TEI objects

(For original source of these comments, see tei-council thread [http://lists.village.virginia.edu/pipermail/tei-council/2008/010041.html Quoting a TEI Object] from September 2008. DS has created a new wiki page for discussing [[Council:stable references|stable references]].)

[LR] In many cases, one has to map schemas and describe the mappings by reference to actual objects in the respective encoding schemes. In this context do (should) we have a mechanism to refer uniquely to TEI objects, beyond the reference to the TEI namespace (<author> in http://www.tei-c.org/ns/1.0), sort of TEI unique identifiers?

[JC] I'd think the proper way to cite an element, class, or datatype generally is to point to its reference page. http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-tree.html

However, we might want to re-examine that... while the hierarchy should remain the same, deprecated elements (etc.) disappear. I have no way easy way to point to something at a particular date in time...unless maybe I point to it at a particular revision in the SVN source tree?

Pointing to a location in the SVN source tree isn't necessarily very pretty but does work and is accurate:

See for example an earlier version of <event>: http://tei.svn.sourceforge.net/viewvc/tei/trunk/P5/Source/Specs/event.xml?revision=231&view=markup

As a cognate example, I can point to any revision of a page in the TEI wiki at any point in its history. We should be able to do this, somehow, in the official way we are meant to cite TEI sources as changing objects in time.

However, maybe an easier solution is to cite:
http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-event.html
but on the generated reference pages like this contain a link to the appropriate place in the SVN repository? i.e.
http://tei.svn.sourceforge.net/viewvc/tei/trunk/P5/Source/Specs/event.xml?view=log
which lists all the revisions.

[AC] The only place on the website where I am ware there are some recommendations with URLs is the citation page:
http://www.tei-c.org/Guidelines/access.xml

This could certainly be enriched with notes on how to point to an element on the line James suggests, but in that case would the version number be enough to point to particular revisions?

[DS] As an alternative to using a TEI-specific convention for citing URLs, we
might want to consider adopting one or another of the standard systems
for permanent identifiers, for example DOI (Digital Object Identifier).

In the case of DOI, there would be some fairly minimal costs involved to
register the DOIs with one of the national registries, but some more
extensive costs in human time to set up a good system for mapping from
our existing nomenclature to a set of DOI identifiers. (Publishers
typically use DOIs to identify individual books or journal articles, but
they can be more granular: every reference page in the Guidelines could
have its own DOI, for example.)

The advantage of doing this would be that anyone accustomed to using
DOIs for citations could simply cite a DOI. So instead of the reference
for <name> in the Guidelines

http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-name.html

we would use something like

doi:10.1111/tei-p5-doc:en:ref-name

which would be resolved to the actual Web address by a DOI resolver.
(Many journal DOIs are mostly numeric but the syntax allows more
human-readable names).

If we seriously want to consider an option like this, we should put out
a call to the librarians/metadata gurus in our community for assistance
with implementation.

[[Category:Council]]

Council

2015-07-27T13:42:24Z

Hcayless: /* Meetings */

The TEI Technical Council, often referred to as 'TEI Council' or 'Council', is the elected body that is responsible for maintaining and implementing the TEI Guidelines. See the [http://www.tei-c.org/Activities/Council/ Council section of the TEI-C website] for archived documents, and [[TEI-Council-FAQ]] for a Council FAQ. The TEI Council also uses this page to store some of its draft agendas and creates pages in the [[:Category: Council|category reserved for use by TEI Council]].

== Meetings ==

See the [[Council-Meeting-Checklist|checklist for organizing a face-to-face meeting]].

{| border="1"
! Meeting date and place
! Agenda
! Minutes
! Action items
|-
|2015-05/27/28/29 Face to face in Ann Arbor, MI, USA
|[[Council Agenda 2015-05]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm69.xml final minutes]
|(in minutes)
|-
|2015-04-24 Teleconference
|[[Council Agenda 2015-04]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm68.xml final minutes]
|(in minutes)
|-
|2015-03-27 Teleconference
|[[Council Agenda 2015-03]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm67.xml final minutes]
|(in minutes)
|-
|2015-02-27 Teleconference
|[[Council agenda 2015-02]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm66.xml final minutes]
|(in minutes)
|-
|2015-01-30 Teleconference
|[[Council agenda 2015-01]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm65.xml final minutes]
|(in minutes)
|-
|2014-12-05 Teleconference
|[[Council agenda 2014-12]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm64.xml final minutes]
|(in minutes)
|-
|2014-11-17/18/19 Face to Face in Durham, NC, USA
|[[Council agenda 2014-11]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm63.xml final minutes]
|(in minutes)
|-
|2014-10-03 Teleconference
|[[Council agenda 2014-10]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm62.xml final minutes]
|(in minutes)
|-
|2014-08-01 Teleconference
|[[Council agenda 2014-08]]
||[http://www.tei-c.org/Activities/Council/Meetings/tcm61.xml final minutes]
|(in minutes)
|-
|2014-06-30/07-02 Face to Face in Oxford
|[[Council agenda 2014-06]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm60.xml final minutes]
| (in minutes)
|-
|2014-05-30 Teleconference
|[[Council agenda 2014-05]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm59.xml final minutes]
| (in minutes)
|-
|2014-03-07 Teleconference
|[[Council agenda 2014-03]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm58.xml final minutes]
| (in minutes)
|-
|2014-01-10 Teleconference
|[[Council agenda 2014-01]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm57.xml final minutes]
|
|-
|2013-11-11 to 2013-11-13 face-to-face Oxford
|[[Council agenda 2013-11]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm56.xml final minutes]
|[[Oxford2013-Actions2]]
|-
|2013-10-21 Teleconference
|[[Council agenda 2013-10]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm55.xml final minutes]
|
|-
|2013-04-11 to 2013-04-13 face-to-face Providence
|[[Council agenda 2013-04]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm54.xml final minutes]
|[[Council actions 2013-04]]
|-
| 2012-12-13 teleconference
| [[Council agenda 2012-12]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm53.xml final minutes]
|
|-
| 2012-09-19 to 2012-09-21 face-to-face meeting Oxford
| [[Council agenda 2012-09]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm52.xml final minutes]
| [[Oxford2012-Actions]]
|-
| 2012-08-09 teleconference
| [[Council agenda 2012-08]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm51.xml final minutes]
|
|-
| 2012-04-15 to 2012-04-18 face-to-face meeting Ann Arbor
| [[Council agenda 2012-04]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm50.xml final minutes]
| [[AnnArbor2012-Actions]]
|-
| 2012-02-28 Teleconference
| [[Council agenda 2012-02]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm49.xml final minutes]
|
|-
| 2011-11-07 to 2011-11-09 face-to-face meeting Paris
| [[Council agenda 2011-11]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm48.xml final minutes]
|
|-
| 2011-08-17 teleconference
|
| [http://www.tei-c.org/Activities/Council/Meetings/tcm47.xml final minutes]
|
|-
| 2011-04-11 to 2011-04-13 face-to-face meeting Chicago
| [[Council agenda 2011-04]]
| [[Council notes 2011-04]], [http://www.tei-c.org/Activities/Council/Meetings/tcm46.xml final minutes]
|
|-
| 2010-10 feature request assignments
| colspan="3" align="center" | [[Council FR assignments]]
|-
| 2010-04-28 to 2010-04-30 face-to-face meeting Dublin
| [[Council agenda 2010-04]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm45.xml final minutes]
|
|-
| 2010-02-08 teleconference
|
| [http://www.tei-c.org/Activities/Council/Meetings/tcm44.xml final minutes]
|
|-
| 2009-12-07 teleconference
|
| [http://www.tei-c.org/Activities/Council/Meetings/tcm43.xml final minutes]
|
|-
| 2009-10-13 teleconference
| [[Council agenda 2009-10]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm42.xml final minutes]
|
|-
| 2009-04-01 to 2009-04-03 face-to-face meeting Lyon
| [[Council 2009-04]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm41.xml final minutes]
|
|-
| 2008-10-07 teleconference
| [[Council agenda 2008-10]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm40.xml final minutes]
|
|-
| colspan="4" align="center" | For minutes of previous meetings, see [http://www.tei-c.org/Activities/Council/Meetings/ minutes on TEI-C website]
|}

== Workgroups ==

A [http://www.tei-c.org/Activities/Workgroups/index.xml full list is on the TEI-C website] and the following wiki pages:

* [[Ad-hoc committee on encoding of bibliographic citations]]
* [[Text Directionality Workgroup]]

== Old notes ==

=== Item for further consideration ===
* Stable URIs to discrete bits of the guidelines

=== Issues for next F2F ===

* Discussion on ODD and its evolution--[[User:Romary|Romary]] 02:34, 9 September 2008 (EDT)

cf. @usage in elementSpec

ODD modifing an ODD (ODD architecture)

Namespaces

* Evolution of Roma

Proposal (SR): rewriting Roma almost entirely in Javascript, interacting with web services to deliver TEI and to generate outputs. The Javascript would grab a copy of TEI (cut down) from a chosen server, and load it into memory. Then it would use that to help you build your ODD. when you were done, it would send the ODD document to a web service whose job is to return a schema or documentation back to the browsers. So Roma would be a Javascript ODD editor, not needing server support beyond a simple Apache, but closely coupled to a pair of generic web services. The generator web service would be identical code to the Vesta desktop

Additional functionalities needed (PB):

- adding copy element functionality,

- supporting the creation/manipulation of content models (instead of the user having to write the models),

- support/help in creating schematron constraints?

- TEI schema validation service (cf. also ISO project)

* should the TEI-C we produce a general purpose online service which can validate and process documents (cf. ISO work)

=== Highlights to be brought to the TEI MM 2008 ===

=== Topics (could be moved up to one F2F or Telco meeting ===

* Stable reference to TEI objects

(For original source of these comments, see tei-council thread [http://lists.village.virginia.edu/pipermail/tei-council/2008/010041.html Quoting a TEI Object] from September 2008. DS has created a new wiki page for discussing [[Council:stable references|stable references]].)

[LR] In many cases, one has to map schemas and describe the mappings by reference to actual objects in the respective encoding schemes. In this context do (should) we have a mechanism to refer uniquely to TEI objects, beyond the reference to the TEI namespace (<author> in http://www.tei-c.org/ns/1.0), sort of TEI unique identifiers?

[JC] I'd think the proper way to cite an element, class, or datatype generally is to point to its reference page. http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-tree.html

However, we might want to re-examine that... while the hierarchy should remain the same, deprecated elements (etc.) disappear. I have no way easy way to point to something at a particular date in time...unless maybe I point to it at a particular revision in the SVN source tree?

Pointing to a location in the SVN source tree isn't necessarily very pretty but does work and is accurate:

See for example an earlier version of <event>: http://tei.svn.sourceforge.net/viewvc/tei/trunk/P5/Source/Specs/event.xml?revision=231&view=markup

As a cognate example, I can point to any revision of a page in the TEI wiki at any point in its history. We should be able to do this, somehow, in the official way we are meant to cite TEI sources as changing objects in time.

However, maybe an easier solution is to cite:
http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-event.html
but on the generated reference pages like this contain a link to the appropriate place in the SVN repository? i.e.
http://tei.svn.sourceforge.net/viewvc/tei/trunk/P5/Source/Specs/event.xml?view=log
which lists all the revisions.

[AC] The only place on the website where I am ware there are some recommendations with URLs is the citation page:
http://www.tei-c.org/Guidelines/access.xml

This could certainly be enriched with notes on how to point to an element on the line James suggests, but in that case would the version number be enough to point to particular revisions?

[DS] As an alternative to using a TEI-specific convention for citing URLs, we
might want to consider adopting one or another of the standard systems
for permanent identifiers, for example DOI (Digital Object Identifier).

In the case of DOI, there would be some fairly minimal costs involved to
register the DOIs with one of the national registries, but some more
extensive costs in human time to set up a good system for mapping from
our existing nomenclature to a set of DOI identifiers. (Publishers
typically use DOIs to identify individual books or journal articles, but
they can be more granular: every reference page in the Guidelines could
have its own DOI, for example.)

The advantage of doing this would be that anyone accustomed to using
DOIs for citations could simply cite a DOI. So instead of the reference
for <name> in the Guidelines

http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-name.html

we would use something like

doi:10.1111/tei-p5-doc:en:ref-name

which would be resolved to the actual Web address by a DOI resolver.
(Many journal DOIs are mostly numeric but the syntax allows more
human-readable names).

If we seriously want to consider an option like this, we should put out
a call to the librarians/metadata gurus in our community for assistance
with implementation.

[[Category:Council]]

Council Agenda 2015-05

2015-05-25T13:44:13Z

Hcayless: /* Thursday 28 May 2015 */

== Draft Agenda for TEI Technical Council Meeting May 27–30, 2015 ==
[https://docs.google.com/document/d/1V7RB54nYMKeXPqPAGxjbKmXwViz0vLFfwzGo4QleYYU/edit?usp=sharing Minutes document]

== Thursday 28 May 2015 ==
09:00 - 10:30
* Agenda discussion
10:30 - 10:45
* Break
10:45 - 13:00
* Ticket Discussion and Assignment
13:00 - 14:30
* Lunch
14:30 - 16:00 (15:30 - Tea Break)
* Tickets processing then recap / other discussion
16:00 - 17:00
* Ticket implementation or other TEI Work
18:00-

== Friday 29 May 2015 ==
09:00 - 10:00
* Ticket discussion and assignment
10:00 – 10:50
* Skype with Laurent Romary about standoff
10:50 – 11:00
* Break
11:00 - 13:00
* Skype with Sebastian about TEI Simple
13:00 - 14:30
* Lunch
14:30 - 16:00 (15:30 - Tea Break)
* Tickets processing then recap and other discussion
16:00 - 17:00
* Ticket implementation or other TEI Work
18:00-

== Saturday 30 May 2015 ==
09:00 - 10:00
* Convene in coffee shop? Ticket implementation or other work
10:00 - 11:30
* Ticket Discussion and Assignment
11:30 - 11:45
* Break
11:45 - 13:00
* Tickets processing then recap / other discussion
13:00 - 14:30
* Lunch / departure for those who need to
14:30 - 17:00
* Ticket implementation or other TEI Work
18:00-

Council Agenda 2015-05

2015-05-25T13:35:59Z

Hcayless: /* Saturday 30 May 2015 */

== Thursday 28 May 2015 ==
09:00 - 10:30
* Agenda discussion
10:30 - 10:45
* Break
10:45 - 13:00
* Ticket Discussion and Assignment
13:00 - 14:30
* Lunch
14:30 - 16:00 (15:30 - Tea Break)
* Tickets processing then recap / other discussion
16:00 - 17:00
* Ticket implementation or other TEI Work
18:00-

== Friday 29 May 2015 ==
09:00 - 10:00
* Ticket discussion and assignment
10:00 – 10:50
* Skype with Laurent Romary about standoff
10:50 – 11:00
* Break
11:00 - 13:00
* Skype with Sebastian about TEI Simple
13:00 - 14:30
* Lunch
14:30 - 16:00 (15:30 - Tea Break)
* Tickets processing then recap and other discussion
16:00 - 17:00
* Ticket implementation or other TEI Work
18:00-

== Saturday 30 May 2015 ==
09:00 - 10:00
* Convene in coffee shop? Ticket implementation or other work
10:00 - 11:30
* Ticket Discussion and Assignment
11:30 - 11:45
* Break
11:45 - 13:00
* Tickets processing then recap / other discussion
13:00 - 14:30
* Lunch / departure for those who need to
14:30 - 17:00
* Ticket implementation or other TEI Work
18:00-

Council

2015-05-25T13:34:22Z

Hcayless: /* Meetings */

The TEI Technical Council, often referred to as 'TEI Council' or 'Council', is the elected body that is responsible for maintaining and implementing the TEI Guidelines. See the [http://www.tei-c.org/Activities/Council/ Council section of the TEI-C website] for archived documents, and [[TEI-Council-FAQ]] for a Council FAQ. The TEI Council also uses this page to store some of its draft agendas and creates pages in the [[:Category: Council|category reserved for use by TEI Council]].

== Meetings ==

See the [[Council-Meeting-Checklist|checklist for organizing a face-to-face meeting]].

{| border="1"
! Meeting date and place
! Agenda
! Minutes
! Action items
|-
|2015-05/27/28/29 Face to face in Ann Arbor, MI, USA
|[[Council Agenda 2015-05]]
|
|
|-
|2015-04-24 Teleconference
|[[Council Agenda 2015-04]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm68.xml final minutes]
|(in minutes)
|-
|2015-03-27 Teleconference
|[[Council Agenda 2015-03]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm67.xml final minutes]
|(in minutes)
|-
|2015-02-27 Teleconference
|[[Council agenda 2015-02]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm66.xml final minutes]
|(in minutes)
|-
|2015-01-30 Teleconference
|[[Council agenda 2015-01]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm65.xml final minutes]
|(in minutes)
|-
|2014-12-05 Teleconference
|[[Council agenda 2014-12]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm64.xml final minutes]
|(in minutes)
|-
|2014-11-17/18/19 Face to Face in Durham, NC, USA
|[[Council agenda 2014-11]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm63.xml final minutes]
|(in minutes)
|-
|2014-10-03 Teleconference
|[[Council agenda 2014-10]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm62.xml final minutes]
|(in minutes)
|-
|2014-08-01 Teleconference
|[[Council agenda 2014-08]]
||[http://www.tei-c.org/Activities/Council/Meetings/tcm61.xml final minutes]
|(in minutes)
|-
|2014-06-30/07-02 Face to Face in Oxford
|[[Council agenda 2014-06]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm60.xml final minutes]
| (in minutes)
|-
|2014-05-30 Teleconference
|[[Council agenda 2014-05]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm59.xml final minutes]
| (in minutes)
|-
|2014-03-07 Teleconference
|[[Council agenda 2014-03]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm58.xml final minutes]
| (in minutes)
|-
|2014-01-10 Teleconference
|[[Council agenda 2014-01]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm57.xml final minutes]
|
|-
|2013-11-11 to 2013-11-13 face-to-face Oxford
|[[Council agenda 2013-11]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm56.xml final minutes]
|[[Oxford2013-Actions2]]
|-
|2013-10-21 Teleconference
|[[Council agenda 2013-10]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm55.xml final minutes]
|
|-
|2013-04-11 to 2013-04-13 face-to-face Providence
|[[Council agenda 2013-04]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm54.xml final minutes]
|[[Council actions 2013-04]]
|-
| 2012-12-13 teleconference
| [[Council agenda 2012-12]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm53.xml final minutes]
|
|-
| 2012-09-19 to 2012-09-21 face-to-face meeting Oxford
| [[Council agenda 2012-09]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm52.xml final minutes]
| [[Oxford2012-Actions]]
|-
| 2012-08-09 teleconference
| [[Council agenda 2012-08]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm51.xml final minutes]
|
|-
| 2012-04-15 to 2012-04-18 face-to-face meeting Ann Arbor
| [[Council agenda 2012-04]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm50.xml final minutes]
| [[AnnArbor2012-Actions]]
|-
| 2012-02-28 Teleconference
| [[Council agenda 2012-02]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm49.xml final minutes]
|
|-
| 2011-11-07 to 2011-11-09 face-to-face meeting Paris
| [[Council agenda 2011-11]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm48.xml final minutes]
|
|-
| 2011-08-17 teleconference
|
| [http://www.tei-c.org/Activities/Council/Meetings/tcm47.xml final minutes]
|
|-
| 2011-04-11 to 2011-04-13 face-to-face meeting Chicago
| [[Council agenda 2011-04]]
| [[Council notes 2011-04]], [http://www.tei-c.org/Activities/Council/Meetings/tcm46.xml final minutes]
|
|-
| 2010-10 feature request assignments
| colspan="3" align="center" | [[Council FR assignments]]
|-
| 2010-04-28 to 2010-04-30 face-to-face meeting Dublin
| [[Council agenda 2010-04]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm45.xml final minutes]
|
|-
| 2010-02-08 teleconference
|
| [http://www.tei-c.org/Activities/Council/Meetings/tcm44.xml final minutes]
|
|-
| 2009-12-07 teleconference
|
| [http://www.tei-c.org/Activities/Council/Meetings/tcm43.xml final minutes]
|
|-
| 2009-10-13 teleconference
| [[Council agenda 2009-10]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm42.xml final minutes]
|
|-
| 2009-04-01 to 2009-04-03 face-to-face meeting Lyon
| [[Council 2009-04]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm41.xml final minutes]
|
|-
| 2008-10-07 teleconference
| [[Council agenda 2008-10]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm40.xml final minutes]
|
|-
| colspan="4" align="center" | For minutes of previous meetings, see [http://www.tei-c.org/Activities/Council/Meetings/ minutes on TEI-C website]
|}

== Workgroups ==

A [http://www.tei-c.org/Activities/Workgroups/index.xml full list is on the TEI-C website] and the following wiki pages:

* [[Ad-hoc committee on encoding of bibliographic citations]]
* [[Text Directionality Workgroup]]

== Old notes ==

=== Item for further consideration ===
* Stable URIs to discrete bits of the guidelines

=== Issues for next F2F ===

* Discussion on ODD and its evolution--[[User:Romary|Romary]] 02:34, 9 September 2008 (EDT)

cf. @usage in elementSpec

ODD modifing an ODD (ODD architecture)

Namespaces

* Evolution of Roma

Proposal (SR): rewriting Roma almost entirely in Javascript, interacting with web services to deliver TEI and to generate outputs. The Javascript would grab a copy of TEI (cut down) from a chosen server, and load it into memory. Then it would use that to help you build your ODD. when you were done, it would send the ODD document to a web service whose job is to return a schema or documentation back to the browsers. So Roma would be a Javascript ODD editor, not needing server support beyond a simple Apache, but closely coupled to a pair of generic web services. The generator web service would be identical code to the Vesta desktop

Additional functionalities needed (PB):

- adding copy element functionality,

- supporting the creation/manipulation of content models (instead of the user having to write the models),

- support/help in creating schematron constraints?

- TEI schema validation service (cf. also ISO project)

* should the TEI-C we produce a general purpose online service which can validate and process documents (cf. ISO work)

=== Highlights to be brought to the TEI MM 2008 ===

=== Topics (could be moved up to one F2F or Telco meeting ===

* Stable reference to TEI objects

(For original source of these comments, see tei-council thread [http://lists.village.virginia.edu/pipermail/tei-council/2008/010041.html Quoting a TEI Object] from September 2008. DS has created a new wiki page for discussing [[Council:stable references|stable references]].)

[LR] In many cases, one has to map schemas and describe the mappings by reference to actual objects in the respective encoding schemes. In this context do (should) we have a mechanism to refer uniquely to TEI objects, beyond the reference to the TEI namespace (<author> in http://www.tei-c.org/ns/1.0), sort of TEI unique identifiers?

[JC] I'd think the proper way to cite an element, class, or datatype generally is to point to its reference page. http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-tree.html

However, we might want to re-examine that... while the hierarchy should remain the same, deprecated elements (etc.) disappear. I have no way easy way to point to something at a particular date in time...unless maybe I point to it at a particular revision in the SVN source tree?

Pointing to a location in the SVN source tree isn't necessarily very pretty but does work and is accurate:

See for example an earlier version of <event>: http://tei.svn.sourceforge.net/viewvc/tei/trunk/P5/Source/Specs/event.xml?revision=231&view=markup

As a cognate example, I can point to any revision of a page in the TEI wiki at any point in its history. We should be able to do this, somehow, in the official way we are meant to cite TEI sources as changing objects in time.

However, maybe an easier solution is to cite:
http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-event.html
but on the generated reference pages like this contain a link to the appropriate place in the SVN repository? i.e.
http://tei.svn.sourceforge.net/viewvc/tei/trunk/P5/Source/Specs/event.xml?view=log
which lists all the revisions.

[AC] The only place on the website where I am ware there are some recommendations with URLs is the citation page:
http://www.tei-c.org/Guidelines/access.xml

This could certainly be enriched with notes on how to point to an element on the line James suggests, but in that case would the version number be enough to point to particular revisions?

[DS] As an alternative to using a TEI-specific convention for citing URLs, we
might want to consider adopting one or another of the standard systems
for permanent identifiers, for example DOI (Digital Object Identifier).

In the case of DOI, there would be some fairly minimal costs involved to
register the DOIs with one of the national registries, but some more
extensive costs in human time to set up a good system for mapping from
our existing nomenclature to a set of DOI identifiers. (Publishers
typically use DOIs to identify individual books or journal articles, but
they can be more granular: every reference page in the Guidelines could
have its own DOI, for example.)

The advantage of doing this would be that anyone accustomed to using
DOIs for citations could simply cite a DOI. So instead of the reference
for <name> in the Guidelines

http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-name.html

we would use something like

doi:10.1111/tei-p5-doc:en:ref-name

which would be resolved to the actual Web address by a DOI resolver.
(Many journal DOIs are mostly numeric but the syntax allows more
human-readable names).

If we seriously want to consider an option like this, we should put out
a call to the librarians/metadata gurus in our community for assistance
with implementation.

[[Category:Council]]

Council Agenda 2015-05

2015-05-21T16:28:43Z

Hcayless: Created page with "== Thursday 28 May 2015 == 09:00 - 10:30 * Agenda discussion 10:30 - 10:45 * Break 10:45 - 13:00 * Ticket Discussion and Assignment 13:00 - 14:30 * Lunch 14:30 - 16:00 (15:30 ..."

== Thursday 28 May 2015 ==
09:00 - 10:30
* Agenda discussion
10:30 - 10:45
* Break
10:45 - 13:00
* Ticket Discussion and Assignment
13:00 - 14:30
* Lunch
14:30 - 16:00 (15:30 - Tea Break)
* Tickets processing then recap / other discussion
16:00 - 17:00
* Ticket implementation or other TEI Work
18:00-

== Friday 29 May 2015 ==
09:00 - 10:00
* Ticket discussion and assignment
10:00 – 10:50
* Skype with Laurent Romary about standoff
10:50 – 11:00
* Break
11:00 - 13:00
* Skype with Sebastian about TEI Simple
13:00 - 14:30
* Lunch
14:30 - 16:00 (15:30 - Tea Break)
* Tickets processing then recap and other discussion
16:00 - 17:00
* Ticket implementation or other TEI Work
18:00-

== Saturday 30 May 2015 ==
10:00 - 11:30
* Ticket Discussion and Assignment
11:30 - 11:45
* Break
11:45 - 13:00
* Tickets processing then recap / other discussion
13:00 - 14:30
* Lunch / departure for those who need to
14:30 - 17:00
* Ticket implementation or other TEI Work
18:00-

Council Agenda 2015-04

2015-04-17T16:06:07Z

Hcayless: /* Teleconference 2015-04-24 13:30 GMT */

== Teleconference 2015-04-24 13:30 GMT ==

* Release 2.8.1? (MH)
* 2015 Nominating Committee (need 2 volunteers from Council)
* Transcription of Spoken Language Draft followup (HC)
* standoff discussion (PWS) (see [https://github.com/laurentromary/stdfSpec Laurent's repo])
* Terminology (see [http://sourceforge.net/p/tei/feature-requests/482/ FR 482])
* Prep for May F2F
* Ticket review
* Other business?

Council Agenda 2015-03

2015-04-16T11:51:11Z

Hcayless: /* Teleconference 2015-02-27 13:30 GMT */

== Teleconference 2015-03-27 13:30 GMT ==

* Review of action items from last telecon (see [[http://www.tei-c.org/Activities/Council/Meetings/tcm66.xml minutes]]).
* JTEI integration into P5, Stylesheets and Oxygen plugin (MH).
* Update on Pure ODD (LB)
* What's in/out of the upcoming release?
* Confirm details of release (code freeze starts today; RV is release technician; release on Easter Monday, 2015-04-06)
* other items?

Council Agenda 2015-04

2015-04-16T11:50:50Z

Hcayless: Created page with "== Teleconference 2015-04-24 13:30 GMT == * Release 2.8.1? * Prep for May F2F * Other business?"

== Teleconference 2015-04-24 13:30 GMT ==

* Release 2.8.1?
* Prep for May F2F
* Other business?

Council

2015-04-16T11:48:37Z

Hcayless: /* Meetings */

The TEI Technical Council, often referred to as 'TEI Council' or 'Council', is the elected body that is responsible for maintaining and implementing the TEI Guidelines. See the [http://www.tei-c.org/Activities/Council/ Council section of the TEI-C website] for archived documents, and [[TEI-Council-FAQ]] for a Council FAQ. The TEI Council also uses this page to store some of its draft agendas and creates pages in the [[:Category: Council|category reserved for use by TEI Council]].

== Meetings ==

See the [[Council-Meeting-Checklist|checklist for organizing a face-to-face meeting]].

{| border="1"
! Meeting date and place
! Agenda
! Minutes
! Action items
|-
|2051-04-24 Teleconference
|[[Council Agenda 2015-04]]
|
|
|-
|2015-03-27 Teleconference
|[[Council Agenda 2015-03]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm67.xml final minutes]
|(in minutes)
|-
|2015-02-27 Teleconference
|[[Council agenda 2015-02]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm66.xml final minutes]
|(in minutes)
|-
|2015-01-30 Teleconference
|[[Council agenda 2015-01]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm65.xml final minutes]
|(in minutes)
|-
|2014-12-05 Teleconference
|[[Council agenda 2014-12]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm64.xml final minutes]
|(in minutes)
|-
|2014-11-17/18/19 Face to Face in Durham, NC, USA
|[[Council agenda 2014-11]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm63.xml final minutes]
|(in minutes)
|-
|2014-10-03 Teleconference
|[[Council agenda 2014-10]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm62.xml final minutes]
|(in minutes)
|-
|2014-08-01 Teleconference
|[[Council agenda 2014-08]]
||[http://www.tei-c.org/Activities/Council/Meetings/tcm61.xml final minutes]
|(in minutes)
|-
|2014-06-30/07-02 Face to Face in Oxford
|[[Council agenda 2014-06]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm60.xml final minutes]
| (in minutes)
|-
|2014-05-30 Teleconference
|[[Council agenda 2014-05]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm59.xml final minutes]
| (in minutes)
|-
|2014-03-07 Teleconference
|[[Council agenda 2014-03]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm58.xml final minutes]
| (in minutes)
|-
|2014-01-10 Teleconference
|[[Council agenda 2014-01]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm57.xml final minutes]
|
|-
|2013-11-11 to 2013-11-13 face-to-face Oxford
|[[Council agenda 2013-11]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm56.xml final minutes]
|[[Oxford2013-Actions2]]
|-
|2013-10-21 Teleconference
|[[Council agenda 2013-10]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm55.xml final minutes]
|
|-
|2013-04-11 to 2013-04-13 face-to-face Providence
|[[Council agenda 2013-04]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm54.xml final minutes]
|[[Council actions 2013-04]]
|-
| 2012-12-13 teleconference
| [[Council agenda 2012-12]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm53.xml final minutes]
|
|-
| 2012-09-19 to 2012-09-21 face-to-face meeting Oxford
| [[Council agenda 2012-09]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm52.xml final minutes]
| [[Oxford2012-Actions]]
|-
| 2012-08-09 teleconference
| [[Council agenda 2012-08]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm51.xml final minutes]
|
|-
| 2012-04-15 to 2012-04-18 face-to-face meeting Ann Arbor
| [[Council agenda 2012-04]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm50.xml final minutes]
| [[AnnArbor2012-Actions]]
|-
| 2012-02-28 Teleconference
| [[Council agenda 2012-02]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm49.xml final minutes]
|
|-
| 2011-11-07 to 2011-11-09 face-to-face meeting Paris
| [[Council agenda 2011-11]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm48.xml final minutes]
|
|-
| 2011-08-17 teleconference
|
| [http://www.tei-c.org/Activities/Council/Meetings/tcm47.xml final minutes]
|
|-
| 2011-04-11 to 2011-04-13 face-to-face meeting Chicago
| [[Council agenda 2011-04]]
| [[Council notes 2011-04]], [http://www.tei-c.org/Activities/Council/Meetings/tcm46.xml final minutes]
|
|-
| 2010-10 feature request assignments
| colspan="3" align="center" | [[Council FR assignments]]
|-
| 2010-04-28 to 2010-04-30 face-to-face meeting Dublin
| [[Council agenda 2010-04]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm45.xml final minutes]
|
|-
| 2010-02-08 teleconference
|
| [http://www.tei-c.org/Activities/Council/Meetings/tcm44.xml final minutes]
|
|-
| 2009-12-07 teleconference
|
| [http://www.tei-c.org/Activities/Council/Meetings/tcm43.xml final minutes]
|
|-
| 2009-10-13 teleconference
| [[Council agenda 2009-10]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm42.xml final minutes]
|
|-
| 2009-04-01 to 2009-04-03 face-to-face meeting Lyon
| [[Council 2009-04]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm41.xml final minutes]
|
|-
| 2008-10-07 teleconference
| [[Council agenda 2008-10]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm40.xml final minutes]
|
|-
| colspan="4" align="center" | For minutes of previous meetings, see [http://www.tei-c.org/Activities/Council/Meetings/ minutes on TEI-C website]
|}

== Workgroups ==

A [http://www.tei-c.org/Activities/Workgroups/index.xml full list is on the TEI-C website] and the following wiki pages:

* [[Ad-hoc committee on encoding of bibliographic citations]]
* [[Text Directionality Workgroup]]

== Old notes ==

=== Item for further consideration ===
* Stable URIs to discrete bits of the guidelines

=== Issues for next F2F ===

* Discussion on ODD and its evolution--[[User:Romary|Romary]] 02:34, 9 September 2008 (EDT)

cf. @usage in elementSpec

ODD modifing an ODD (ODD architecture)

Namespaces

* Evolution of Roma

Proposal (SR): rewriting Roma almost entirely in Javascript, interacting with web services to deliver TEI and to generate outputs. The Javascript would grab a copy of TEI (cut down) from a chosen server, and load it into memory. Then it would use that to help you build your ODD. when you were done, it would send the ODD document to a web service whose job is to return a schema or documentation back to the browsers. So Roma would be a Javascript ODD editor, not needing server support beyond a simple Apache, but closely coupled to a pair of generic web services. The generator web service would be identical code to the Vesta desktop

Additional functionalities needed (PB):

- adding copy element functionality,

- supporting the creation/manipulation of content models (instead of the user having to write the models),

- support/help in creating schematron constraints?

- TEI schema validation service (cf. also ISO project)

* should the TEI-C we produce a general purpose online service which can validate and process documents (cf. ISO work)

=== Highlights to be brought to the TEI MM 2008 ===

=== Topics (could be moved up to one F2F or Telco meeting ===

* Stable reference to TEI objects

(For original source of these comments, see tei-council thread [http://lists.village.virginia.edu/pipermail/tei-council/2008/010041.html Quoting a TEI Object] from September 2008. DS has created a new wiki page for discussing [[Council:stable references|stable references]].)

[LR] In many cases, one has to map schemas and describe the mappings by reference to actual objects in the respective encoding schemes. In this context do (should) we have a mechanism to refer uniquely to TEI objects, beyond the reference to the TEI namespace (<author> in http://www.tei-c.org/ns/1.0), sort of TEI unique identifiers?

[JC] I'd think the proper way to cite an element, class, or datatype generally is to point to its reference page. http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-tree.html

However, we might want to re-examine that... while the hierarchy should remain the same, deprecated elements (etc.) disappear. I have no way easy way to point to something at a particular date in time...unless maybe I point to it at a particular revision in the SVN source tree?

Pointing to a location in the SVN source tree isn't necessarily very pretty but does work and is accurate:

See for example an earlier version of <event>: http://tei.svn.sourceforge.net/viewvc/tei/trunk/P5/Source/Specs/event.xml?revision=231&view=markup

As a cognate example, I can point to any revision of a page in the TEI wiki at any point in its history. We should be able to do this, somehow, in the official way we are meant to cite TEI sources as changing objects in time.

However, maybe an easier solution is to cite:
http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-event.html
but on the generated reference pages like this contain a link to the appropriate place in the SVN repository? i.e.
http://tei.svn.sourceforge.net/viewvc/tei/trunk/P5/Source/Specs/event.xml?view=log
which lists all the revisions.

[AC] The only place on the website where I am ware there are some recommendations with URLs is the citation page:
http://www.tei-c.org/Guidelines/access.xml

This could certainly be enriched with notes on how to point to an element on the line James suggests, but in that case would the version number be enough to point to particular revisions?

[DS] As an alternative to using a TEI-specific convention for citing URLs, we
might want to consider adopting one or another of the standard systems
for permanent identifiers, for example DOI (Digital Object Identifier).

In the case of DOI, there would be some fairly minimal costs involved to
register the DOIs with one of the national registries, but some more
extensive costs in human time to set up a good system for mapping from
our existing nomenclature to a set of DOI identifiers. (Publishers
typically use DOIs to identify individual books or journal articles, but
they can be more granular: every reference page in the Guidelines could
have its own DOI, for example.)

The advantage of doing this would be that anyone accustomed to using
DOIs for citations could simply cite a DOI. So instead of the reference
for <name> in the Guidelines

http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-name.html

we would use something like

doi:10.1111/tei-p5-doc:en:ref-name

which would be resolved to the actual Web address by a DOI resolver.
(Many journal DOIs are mostly numeric but the syntax allows more
human-readable names).

If we seriously want to consider an option like this, we should put out
a call to the librarians/metadata gurus in our community for assistance
with implementation.

[[Category:Council]]

Council Agenda 2015-03

2015-03-23T11:18:05Z

Hcayless: Created page with "== Teleconference 2015-02-27 13:30 GMT == * Review of action items from last telecon (see http://www.tei-c.org/Activities/Council/Meetings/tcm66.xml minutes). * What's in/ou..."

== Teleconference 2015-02-27 13:30 GMT ==

* Review of action items from last telecon (see [[http://www.tei-c.org/Activities/Council/Meetings/tcm66.xml minutes]]).
* What's in/out of the upcoming release?
* other items?

Council agenda 2015-03

2015-03-23T11:15:26Z

Hcayless: Created page with "== Teleconference 2015-02-27 13:30 GMT == * Pre-release ticket review * Other items?"

== Teleconference 2015-02-27 13:30 GMT ==

* Pre-release ticket review
* Other items?

Council

2015-03-23T11:14:12Z

Hcayless: /* Meetings */

The TEI Technical Council, often referred to as 'TEI Council' or 'Council', is the elected body that is responsible for maintaining and implementing the TEI Guidelines. See the [http://www.tei-c.org/Activities/Council/ Council section of the TEI-C website] for archived documents, and [[TEI-Council-FAQ]] for a Council FAQ. The TEI Council also uses this page to store some of its draft agendas and creates pages in the [[:Category: Council|category reserved for use by TEI Council]].

== Meetings ==

See the [[Council-Meeting-Checklist|checklist for organizing a face-to-face meeting]].

{| border="1"
! Meeting date and place
! Agenda
! Minutes
! Action items
|-
|2015-03-27 Teleconference
|[[Council Agenda 2015-03]]
|
|
|-
|2015-02-27 Teleconference
|[[Council agenda 2015-02]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm66.xml final minutes]
|(in minutes)
|-
|2015-01-30 Teleconference
|[[Council agenda 2015-01]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm65.xml final minutes]
|(in minutes)
|-
|2014-12-05 Teleconference
|[[Council agenda 2014-12]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm64.xml final minutes]
|(in minutes)
|-
|2014-11-17/18/19 Face to Face in Durham, NC, USA
|[[Council agenda 2014-11]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm63.xml final minutes]
|(in minutes)
|-
|2014-10-03 Teleconference
|[[Council agenda 2014-10]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm62.xml final minutes]
|(in minutes)
|-
|2014-08-01 Teleconference
|[[Council agenda 2014-08]]
||[http://www.tei-c.org/Activities/Council/Meetings/tcm61.xml final minutes]
|(in minutes)
|-
|2014-06-30/07-02 Face to Face in Oxford
|[[Council agenda 2014-06]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm60.xml final minutes]
| (in minutes)
|-
|2014-05-30 Teleconference
|[[Council agenda 2014-05]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm59.xml final minutes]
| (in minutes)
|-
|2014-03-07 Teleconference
|[[Council agenda 2014-03]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm58.xml final minutes]
| (in minutes)
|-
|2014-01-10 Teleconference
|[[Council agenda 2014-01]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm57.xml final minutes]
|
|-
|2013-11-11 to 2013-11-13 face-to-face Oxford
|[[Council agenda 2013-11]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm56.xml final minutes]
|[[Oxford2013-Actions2]]
|-
|2013-10-21 Teleconference
|[[Council agenda 2013-10]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm55.xml final minutes]
|
|-
|2013-04-11 to 2013-04-13 face-to-face Providence
|[[Council agenda 2013-04]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm54.xml final minutes]
|[[Council actions 2013-04]]
|-
| 2012-12-13 teleconference
| [[Council agenda 2012-12]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm53.xml final minutes]
|
|-
| 2012-09-19 to 2012-09-21 face-to-face meeting Oxford
| [[Council agenda 2012-09]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm52.xml final minutes]
| [[Oxford2012-Actions]]
|-
| 2012-08-09 teleconference
| [[Council agenda 2012-08]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm51.xml final minutes]
|
|-
| 2012-04-15 to 2012-04-18 face-to-face meeting Ann Arbor
| [[Council agenda 2012-04]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm50.xml final minutes]
| [[AnnArbor2012-Actions]]
|-
| 2012-02-28 Teleconference
| [[Council agenda 2012-02]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm49.xml final minutes]
|
|-
| 2011-11-07 to 2011-11-09 face-to-face meeting Paris
| [[Council agenda 2011-11]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm48.xml final minutes]
|
|-
| 2011-08-17 teleconference
|
| [http://www.tei-c.org/Activities/Council/Meetings/tcm47.xml final minutes]
|
|-
| 2011-04-11 to 2011-04-13 face-to-face meeting Chicago
| [[Council agenda 2011-04]]
| [[Council notes 2011-04]], [http://www.tei-c.org/Activities/Council/Meetings/tcm46.xml final minutes]
|
|-
| 2010-10 feature request assignments
| colspan="3" align="center" | [[Council FR assignments]]
|-
| 2010-04-28 to 2010-04-30 face-to-face meeting Dublin
| [[Council agenda 2010-04]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm45.xml final minutes]
|
|-
| 2010-02-08 teleconference
|
| [http://www.tei-c.org/Activities/Council/Meetings/tcm44.xml final minutes]
|
|-
| 2009-12-07 teleconference
|
| [http://www.tei-c.org/Activities/Council/Meetings/tcm43.xml final minutes]
|
|-
| 2009-10-13 teleconference
| [[Council agenda 2009-10]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm42.xml final minutes]
|
|-
| 2009-04-01 to 2009-04-03 face-to-face meeting Lyon
| [[Council 2009-04]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm41.xml final minutes]
|
|-
| 2008-10-07 teleconference
| [[Council agenda 2008-10]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm40.xml final minutes]
|
|-
| colspan="4" align="center" | For minutes of previous meetings, see [http://www.tei-c.org/Activities/Council/Meetings/ minutes on TEI-C website]
|}

== Workgroups ==

A [http://www.tei-c.org/Activities/Workgroups/index.xml full list is on the TEI-C website] and the following wiki pages:

* [[Ad-hoc committee on encoding of bibliographic citations]]
* [[Text Directionality Workgroup]]

== Old notes ==

=== Item for further consideration ===
* Stable URIs to discrete bits of the guidelines

=== Issues for next F2F ===

* Discussion on ODD and its evolution--[[User:Romary|Romary]] 02:34, 9 September 2008 (EDT)

cf. @usage in elementSpec

ODD modifing an ODD (ODD architecture)

Namespaces

* Evolution of Roma

Proposal (SR): rewriting Roma almost entirely in Javascript, interacting with web services to deliver TEI and to generate outputs. The Javascript would grab a copy of TEI (cut down) from a chosen server, and load it into memory. Then it would use that to help you build your ODD. when you were done, it would send the ODD document to a web service whose job is to return a schema or documentation back to the browsers. So Roma would be a Javascript ODD editor, not needing server support beyond a simple Apache, but closely coupled to a pair of generic web services. The generator web service would be identical code to the Vesta desktop

Additional functionalities needed (PB):

- adding copy element functionality,

- supporting the creation/manipulation of content models (instead of the user having to write the models),

- support/help in creating schematron constraints?

- TEI schema validation service (cf. also ISO project)

* should the TEI-C we produce a general purpose online service which can validate and process documents (cf. ISO work)

=== Highlights to be brought to the TEI MM 2008 ===

=== Topics (could be moved up to one F2F or Telco meeting ===

* Stable reference to TEI objects

(For original source of these comments, see tei-council thread [http://lists.village.virginia.edu/pipermail/tei-council/2008/010041.html Quoting a TEI Object] from September 2008. DS has created a new wiki page for discussing [[Council:stable references|stable references]].)

[LR] In many cases, one has to map schemas and describe the mappings by reference to actual objects in the respective encoding schemes. In this context do (should) we have a mechanism to refer uniquely to TEI objects, beyond the reference to the TEI namespace (<author> in http://www.tei-c.org/ns/1.0), sort of TEI unique identifiers?

[JC] I'd think the proper way to cite an element, class, or datatype generally is to point to its reference page. http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-tree.html

However, we might want to re-examine that... while the hierarchy should remain the same, deprecated elements (etc.) disappear. I have no way easy way to point to something at a particular date in time...unless maybe I point to it at a particular revision in the SVN source tree?

Pointing to a location in the SVN source tree isn't necessarily very pretty but does work and is accurate:

See for example an earlier version of <event>: http://tei.svn.sourceforge.net/viewvc/tei/trunk/P5/Source/Specs/event.xml?revision=231&view=markup

As a cognate example, I can point to any revision of a page in the TEI wiki at any point in its history. We should be able to do this, somehow, in the official way we are meant to cite TEI sources as changing objects in time.

However, maybe an easier solution is to cite:
http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-event.html
but on the generated reference pages like this contain a link to the appropriate place in the SVN repository? i.e.
http://tei.svn.sourceforge.net/viewvc/tei/trunk/P5/Source/Specs/event.xml?view=log
which lists all the revisions.

[AC] The only place on the website where I am ware there are some recommendations with URLs is the citation page:
http://www.tei-c.org/Guidelines/access.xml

This could certainly be enriched with notes on how to point to an element on the line James suggests, but in that case would the version number be enough to point to particular revisions?

[DS] As an alternative to using a TEI-specific convention for citing URLs, we
might want to consider adopting one or another of the standard systems
for permanent identifiers, for example DOI (Digital Object Identifier).

In the case of DOI, there would be some fairly minimal costs involved to
register the DOIs with one of the national registries, but some more
extensive costs in human time to set up a good system for mapping from
our existing nomenclature to a set of DOI identifiers. (Publishers
typically use DOIs to identify individual books or journal articles, but
they can be more granular: every reference page in the Guidelines could
have its own DOI, for example.)

The advantage of doing this would be that anyone accustomed to using
DOIs for citations could simply cite a DOI. So instead of the reference
for <name> in the Guidelines

http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-name.html

we would use something like

doi:10.1111/tei-p5-doc:en:ref-name

which would be resolved to the actual Web address by a DOI resolver.
(Many journal DOIs are mostly numeric but the syntax allows more
human-readable names).

If we seriously want to consider an option like this, we should put out
a call to the librarians/metadata gurus in our community for assistance
with implementation.

[[Category:Council]]

Council

2015-03-23T11:13:56Z

Hcayless: /* Meetings */

The TEI Technical Council, often referred to as 'TEI Council' or 'Council', is the elected body that is responsible for maintaining and implementing the TEI Guidelines. See the [http://www.tei-c.org/Activities/Council/ Council section of the TEI-C website] for archived documents, and [[TEI-Council-FAQ]] for a Council FAQ. The TEI Council also uses this page to store some of its draft agendas and creates pages in the [[:Category: Council|category reserved for use by TEI Council]].

== Meetings ==

See the [[Council-Meeting-Checklist|checklist for organizing a face-to-face meeting]].

{| border="1"
! Meeting date and place
! Agenda
! Minutes
! Action items
|-
|2015-03-27 Teleconference
|[Council Agenda 2015-03]]
|
|
|-
|2015-02-27 Teleconference
|[[Council agenda 2015-02]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm66.xml final minutes]
|(in minutes)
|-
|2015-01-30 Teleconference
|[[Council agenda 2015-01]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm65.xml final minutes]
|(in minutes)
|-
|2014-12-05 Teleconference
|[[Council agenda 2014-12]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm64.xml final minutes]
|(in minutes)
|-
|2014-11-17/18/19 Face to Face in Durham, NC, USA
|[[Council agenda 2014-11]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm63.xml final minutes]
|(in minutes)
|-
|2014-10-03 Teleconference
|[[Council agenda 2014-10]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm62.xml final minutes]
|(in minutes)
|-
|2014-08-01 Teleconference
|[[Council agenda 2014-08]]
||[http://www.tei-c.org/Activities/Council/Meetings/tcm61.xml final minutes]
|(in minutes)
|-
|2014-06-30/07-02 Face to Face in Oxford
|[[Council agenda 2014-06]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm60.xml final minutes]
| (in minutes)
|-
|2014-05-30 Teleconference
|[[Council agenda 2014-05]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm59.xml final minutes]
| (in minutes)
|-
|2014-03-07 Teleconference
|[[Council agenda 2014-03]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm58.xml final minutes]
| (in minutes)
|-
|2014-01-10 Teleconference
|[[Council agenda 2014-01]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm57.xml final minutes]
|
|-
|2013-11-11 to 2013-11-13 face-to-face Oxford
|[[Council agenda 2013-11]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm56.xml final minutes]
|[[Oxford2013-Actions2]]
|-
|2013-10-21 Teleconference
|[[Council agenda 2013-10]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm55.xml final minutes]
|
|-
|2013-04-11 to 2013-04-13 face-to-face Providence
|[[Council agenda 2013-04]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm54.xml final minutes]
|[[Council actions 2013-04]]
|-
| 2012-12-13 teleconference
| [[Council agenda 2012-12]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm53.xml final minutes]
|
|-
| 2012-09-19 to 2012-09-21 face-to-face meeting Oxford
| [[Council agenda 2012-09]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm52.xml final minutes]
| [[Oxford2012-Actions]]
|-
| 2012-08-09 teleconference
| [[Council agenda 2012-08]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm51.xml final minutes]
|
|-
| 2012-04-15 to 2012-04-18 face-to-face meeting Ann Arbor
| [[Council agenda 2012-04]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm50.xml final minutes]
| [[AnnArbor2012-Actions]]
|-
| 2012-02-28 Teleconference
| [[Council agenda 2012-02]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm49.xml final minutes]
|
|-
| 2011-11-07 to 2011-11-09 face-to-face meeting Paris
| [[Council agenda 2011-11]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm48.xml final minutes]
|
|-
| 2011-08-17 teleconference
|
| [http://www.tei-c.org/Activities/Council/Meetings/tcm47.xml final minutes]
|
|-
| 2011-04-11 to 2011-04-13 face-to-face meeting Chicago
| [[Council agenda 2011-04]]
| [[Council notes 2011-04]], [http://www.tei-c.org/Activities/Council/Meetings/tcm46.xml final minutes]
|
|-
| 2010-10 feature request assignments
| colspan="3" align="center" | [[Council FR assignments]]
|-
| 2010-04-28 to 2010-04-30 face-to-face meeting Dublin
| [[Council agenda 2010-04]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm45.xml final minutes]
|
|-
| 2010-02-08 teleconference
|
| [http://www.tei-c.org/Activities/Council/Meetings/tcm44.xml final minutes]
|
|-
| 2009-12-07 teleconference
|
| [http://www.tei-c.org/Activities/Council/Meetings/tcm43.xml final minutes]
|
|-
| 2009-10-13 teleconference
| [[Council agenda 2009-10]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm42.xml final minutes]
|
|-
| 2009-04-01 to 2009-04-03 face-to-face meeting Lyon
| [[Council 2009-04]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm41.xml final minutes]
|
|-
| 2008-10-07 teleconference
| [[Council agenda 2008-10]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm40.xml final minutes]
|
|-
| colspan="4" align="center" | For minutes of previous meetings, see [http://www.tei-c.org/Activities/Council/Meetings/ minutes on TEI-C website]
|}

== Workgroups ==

A [http://www.tei-c.org/Activities/Workgroups/index.xml full list is on the TEI-C website] and the following wiki pages:

* [[Ad-hoc committee on encoding of bibliographic citations]]
* [[Text Directionality Workgroup]]

== Old notes ==

=== Item for further consideration ===
* Stable URIs to discrete bits of the guidelines

=== Issues for next F2F ===

* Discussion on ODD and its evolution--[[User:Romary|Romary]] 02:34, 9 September 2008 (EDT)

cf. @usage in elementSpec

ODD modifing an ODD (ODD architecture)

Namespaces

* Evolution of Roma

Proposal (SR): rewriting Roma almost entirely in Javascript, interacting with web services to deliver TEI and to generate outputs. The Javascript would grab a copy of TEI (cut down) from a chosen server, and load it into memory. Then it would use that to help you build your ODD. when you were done, it would send the ODD document to a web service whose job is to return a schema or documentation back to the browsers. So Roma would be a Javascript ODD editor, not needing server support beyond a simple Apache, but closely coupled to a pair of generic web services. The generator web service would be identical code to the Vesta desktop

Additional functionalities needed (PB):

- adding copy element functionality,

- supporting the creation/manipulation of content models (instead of the user having to write the models),

- support/help in creating schematron constraints?

- TEI schema validation service (cf. also ISO project)

* should the TEI-C we produce a general purpose online service which can validate and process documents (cf. ISO work)

=== Highlights to be brought to the TEI MM 2008 ===

=== Topics (could be moved up to one F2F or Telco meeting ===

* Stable reference to TEI objects

(For original source of these comments, see tei-council thread [http://lists.village.virginia.edu/pipermail/tei-council/2008/010041.html Quoting a TEI Object] from September 2008. DS has created a new wiki page for discussing [[Council:stable references|stable references]].)

[LR] In many cases, one has to map schemas and describe the mappings by reference to actual objects in the respective encoding schemes. In this context do (should) we have a mechanism to refer uniquely to TEI objects, beyond the reference to the TEI namespace (<author> in http://www.tei-c.org/ns/1.0), sort of TEI unique identifiers?

[JC] I'd think the proper way to cite an element, class, or datatype generally is to point to its reference page. http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-tree.html

However, we might want to re-examine that... while the hierarchy should remain the same, deprecated elements (etc.) disappear. I have no way easy way to point to something at a particular date in time...unless maybe I point to it at a particular revision in the SVN source tree?

Pointing to a location in the SVN source tree isn't necessarily very pretty but does work and is accurate:

See for example an earlier version of <event>: http://tei.svn.sourceforge.net/viewvc/tei/trunk/P5/Source/Specs/event.xml?revision=231&view=markup

As a cognate example, I can point to any revision of a page in the TEI wiki at any point in its history. We should be able to do this, somehow, in the official way we are meant to cite TEI sources as changing objects in time.

However, maybe an easier solution is to cite:
http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-event.html
but on the generated reference pages like this contain a link to the appropriate place in the SVN repository? i.e.
http://tei.svn.sourceforge.net/viewvc/tei/trunk/P5/Source/Specs/event.xml?view=log
which lists all the revisions.

[AC] The only place on the website where I am ware there are some recommendations with URLs is the citation page:
http://www.tei-c.org/Guidelines/access.xml

This could certainly be enriched with notes on how to point to an element on the line James suggests, but in that case would the version number be enough to point to particular revisions?

[DS] As an alternative to using a TEI-specific convention for citing URLs, we
might want to consider adopting one or another of the standard systems
for permanent identifiers, for example DOI (Digital Object Identifier).

In the case of DOI, there would be some fairly minimal costs involved to
register the DOIs with one of the national registries, but some more
extensive costs in human time to set up a good system for mapping from
our existing nomenclature to a set of DOI identifiers. (Publishers
typically use DOIs to identify individual books or journal articles, but
they can be more granular: every reference page in the Guidelines could
have its own DOI, for example.)

The advantage of doing this would be that anyone accustomed to using
DOIs for citations could simply cite a DOI. So instead of the reference
for <name> in the Guidelines

http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-name.html

we would use something like

doi:10.1111/tei-p5-doc:en:ref-name

which would be resolved to the actual Web address by a DOI resolver.
(Many journal DOIs are mostly numeric but the syntax allows more
human-readable names).

If we seriously want to consider an option like this, we should put out
a call to the librarians/metadata gurus in our community for assistance
with implementation.

[[Category:Council]]

Council

2015-02-23T13:00:12Z

Hcayless: /* Meetings */

The TEI Technical Council, often referred to as 'TEI Council' or 'Council', is the elected body that is responsible for maintaining and implementing the TEI Guidelines. See the [http://www.tei-c.org/Activities/Council/ Council section of the TEI-C website] for archived documents, and [[TEI-Council-FAQ]] for a Council FAQ. The TEI Council also uses this page to store some of its draft agendas and creates pages in the [[:Category: Council|category reserved for use by TEI Council]].

== Meetings ==

See the [[Council-Meeting-Checklist|checklist for organizing a face-to-face meeting]].

{| border="1"
! Meeting date and place
! Agenda
! Minutes
! Action items
|-
|2015-02-27 Teleconference
|[[Council agenda 2015-02]]
|
|
|-
|2015-01-30 Teleconference
|[[Council agenda 2015-01]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm65.xml final minutes]
|(in minutes)
|-
|2014-12-05 Teleconference
|[[Council agenda 2014-12]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm64.xml final minutes]
|(in minutes)
|-
|2014-11-17/18/19 Face to Face in Durham, NC, USA
|[[Council agenda 2014-11]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm63.xml final minutes]
|(in minutes)
|-
|2014-10-03 Teleconference
|[[Council agenda 2014-10]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm62.xml final minutes]
|(in minutes)
|-
|2014-08-01 Teleconference
|[[Council agenda 2014-08]]
||[http://www.tei-c.org/Activities/Council/Meetings/tcm61.xml final minutes]
|(in minutes)
|-
|2014-06-30/07-02 Face to Face in Oxford
|[[Council agenda 2014-06]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm60.xml final minutes]
| (in minutes)
|-
|2014-05-30 Teleconference
|[[Council agenda 2014-05]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm59.xml final minutes]
| (in minutes)
|-
|2014-03-07 Teleconference
|[[Council agenda 2014-03]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm58.xml final minutes]
| (in minutes)
|-
|2014-01-10 Teleconference
|[[Council agenda 2014-01]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm57.xml final minutes]
|
|-
|2013-11-11 to 2013-11-13 face-to-face Oxford
|[[Council agenda 2013-11]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm56.xml final minutes]
|[[Oxford2013-Actions2]]
|-
|2013-10-21 Teleconference
|[[Council agenda 2013-10]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm55.xml final minutes]
|
|-
|2013-04-11 to 2013-04-13 face-to-face Providence
|[[Council agenda 2013-04]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm54.xml final minutes]
|[[Council actions 2013-04]]
|-
| 2012-12-13 teleconference
| [[Council agenda 2012-12]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm53.xml final minutes]
|
|-
| 2012-09-19 to 2012-09-21 face-to-face meeting Oxford
| [[Council agenda 2012-09]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm52.xml final minutes]
| [[Oxford2012-Actions]]
|-
| 2012-08-09 teleconference
| [[Council agenda 2012-08]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm51.xml final minutes]
|
|-
| 2012-04-15 to 2012-04-18 face-to-face meeting Ann Arbor
| [[Council agenda 2012-04]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm50.xml final minutes]
| [[AnnArbor2012-Actions]]
|-
| 2012-02-28 Teleconference
| [[Council agenda 2012-02]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm49.xml final minutes]
|
|-
| 2011-11-07 to 2011-11-09 face-to-face meeting Paris
| [[Council agenda 2011-11]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm48.xml final minutes]
|
|-
| 2011-08-17 teleconference
|
| [http://www.tei-c.org/Activities/Council/Meetings/tcm47.xml final minutes]
|
|-
| 2011-04-11 to 2011-04-13 face-to-face meeting Chicago
| [[Council agenda 2011-04]]
| [[Council notes 2011-04]], [http://www.tei-c.org/Activities/Council/Meetings/tcm46.xml final minutes]
|
|-
| 2010-10 feature request assignments
| colspan="3" align="center" | [[Council FR assignments]]
|-
| 2010-04-28 to 2010-04-30 face-to-face meeting Dublin
| [[Council agenda 2010-04]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm45.xml final minutes]
|
|-
| 2010-02-08 teleconference
|
| [http://www.tei-c.org/Activities/Council/Meetings/tcm44.xml final minutes]
|
|-
| 2009-12-07 teleconference
|
| [http://www.tei-c.org/Activities/Council/Meetings/tcm43.xml final minutes]
|
|-
| 2009-10-13 teleconference
| [[Council agenda 2009-10]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm42.xml final minutes]
|
|-
| 2009-04-01 to 2009-04-03 face-to-face meeting Lyon
| [[Council 2009-04]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm41.xml final minutes]
|
|-
| 2008-10-07 teleconference
| [[Council agenda 2008-10]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm40.xml final minutes]
|
|-
| colspan="4" align="center" | For minutes of previous meetings, see [http://www.tei-c.org/Activities/Council/Meetings/ minutes on TEI-C website]
|}

== Workgroups ==

A [http://www.tei-c.org/Activities/Workgroups/index.xml full list is on the TEI-C website] and the following wiki pages:

* [[Ad-hoc committee on encoding of bibliographic citations]]
* [[Text Directionality Workgroup]]

== Old notes ==

=== Item for further consideration ===
* Stable URIs to discrete bits of the guidelines

=== Issues for next F2F ===

* Discussion on ODD and its evolution--[[User:Romary|Romary]] 02:34, 9 September 2008 (EDT)

cf. @usage in elementSpec

ODD modifing an ODD (ODD architecture)

Namespaces

* Evolution of Roma

Proposal (SR): rewriting Roma almost entirely in Javascript, interacting with web services to deliver TEI and to generate outputs. The Javascript would grab a copy of TEI (cut down) from a chosen server, and load it into memory. Then it would use that to help you build your ODD. when you were done, it would send the ODD document to a web service whose job is to return a schema or documentation back to the browsers. So Roma would be a Javascript ODD editor, not needing server support beyond a simple Apache, but closely coupled to a pair of generic web services. The generator web service would be identical code to the Vesta desktop

Additional functionalities needed (PB):

- adding copy element functionality,

- supporting the creation/manipulation of content models (instead of the user having to write the models),

- support/help in creating schematron constraints?

- TEI schema validation service (cf. also ISO project)

* should the TEI-C we produce a general purpose online service which can validate and process documents (cf. ISO work)

=== Highlights to be brought to the TEI MM 2008 ===

=== Topics (could be moved up to one F2F or Telco meeting ===

* Stable reference to TEI objects

(For original source of these comments, see tei-council thread [http://lists.village.virginia.edu/pipermail/tei-council/2008/010041.html Quoting a TEI Object] from September 2008. DS has created a new wiki page for discussing [[Council:stable references|stable references]].)

[LR] In many cases, one has to map schemas and describe the mappings by reference to actual objects in the respective encoding schemes. In this context do (should) we have a mechanism to refer uniquely to TEI objects, beyond the reference to the TEI namespace (<author> in http://www.tei-c.org/ns/1.0), sort of TEI unique identifiers?

[JC] I'd think the proper way to cite an element, class, or datatype generally is to point to its reference page. http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-tree.html

However, we might want to re-examine that... while the hierarchy should remain the same, deprecated elements (etc.) disappear. I have no way easy way to point to something at a particular date in time...unless maybe I point to it at a particular revision in the SVN source tree?

Pointing to a location in the SVN source tree isn't necessarily very pretty but does work and is accurate:

See for example an earlier version of <event>: http://tei.svn.sourceforge.net/viewvc/tei/trunk/P5/Source/Specs/event.xml?revision=231&view=markup

As a cognate example, I can point to any revision of a page in the TEI wiki at any point in its history. We should be able to do this, somehow, in the official way we are meant to cite TEI sources as changing objects in time.

However, maybe an easier solution is to cite:
http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-event.html
but on the generated reference pages like this contain a link to the appropriate place in the SVN repository? i.e.
http://tei.svn.sourceforge.net/viewvc/tei/trunk/P5/Source/Specs/event.xml?view=log
which lists all the revisions.

[AC] The only place on the website where I am ware there are some recommendations with URLs is the citation page:
http://www.tei-c.org/Guidelines/access.xml

This could certainly be enriched with notes on how to point to an element on the line James suggests, but in that case would the version number be enough to point to particular revisions?

[DS] As an alternative to using a TEI-specific convention for citing URLs, we
might want to consider adopting one or another of the standard systems
for permanent identifiers, for example DOI (Digital Object Identifier).

In the case of DOI, there would be some fairly minimal costs involved to
register the DOIs with one of the national registries, but some more
extensive costs in human time to set up a good system for mapping from
our existing nomenclature to a set of DOI identifiers. (Publishers
typically use DOIs to identify individual books or journal articles, but
they can be more granular: every reference page in the Guidelines could
have its own DOI, for example.)

The advantage of doing this would be that anyone accustomed to using
DOIs for citations could simply cite a DOI. So instead of the reference
for <name> in the Guidelines

http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-name.html

we would use something like

doi:10.1111/tei-p5-doc:en:ref-name

which would be resolved to the actual Web address by a DOI resolver.
(Many journal DOIs are mostly numeric but the syntax allows more
human-readable names).

If we seriously want to consider an option like this, we should put out
a call to the librarians/metadata gurus in our community for assistance
with implementation.

[[Category:Council]]

Council agenda 2015-02

2015-02-23T12:57:49Z

Hcayless: Created page with "== Teleconference 2015-02-27 13:30 GMT == * Discuss/finalize [https://sourceforge.net/p/tei/feature-requests/505/ redefining msPart] (see: [https://docs.google.com/document/d/1b..."

== Teleconference 2015-02-27 13:30 GMT ==

* Discuss/finalize [https://sourceforge.net/p/tei/feature-requests/505/ redefining msPart] (see: [https://docs.google.com/document/d/1bpBPughQp5sOoB13iTMHMeRd88Mjv12_eGZiQXY-na8/edit# Google Doc] (SG / PWS)
* Discuss [http://lists.tei-c.org/pipermail/tei-council/2015/020458.html TEI Simple report] (JC)
* Discuss [http://bit.ly/1jyZC37 Transcription of Spoken Language] draft (LB)
* Update on [https://sourceforge.net/p/tei/feature-requests/510/ correspDesc proposal] (PWS)
* Other business?

Council agenda 2015-01

2015-01-30T12:58:27Z

Hcayless: /* Teleconference 2015-01-30 14:00 GMT */

== Teleconference 2015-01-30 14:00 GMT ==

* Welcome new members
* (Re-)review of actions from last F2F / unassigned tickets
* Update on [https://sourceforge.net/p/tei/feature-requests/510/ correspDesc proposal] (PWS)
* Update on TEI Simple (JC)
* Update on [https://sourceforge.net/p/tei/feature-requests/505/ redefining msPart] (SG / PWS)
* Dates/times for teleconferences
* Date of next release/release technician
* Date/venue for next F2F

[https://docs.google.com/document/d/1RWrn2wxgYUEGwcY_W5ZhmvboYRnYbbLcctLvPlBTHFE/edit?usp=sharing Minutes]

Council agenda 2015-01

2015-01-27T12:10:57Z

Hcayless: /* Teleconference 2015-01-30 14:00 GMT */

== Teleconference 2015-01-30 14:00 GMT ==

* Welcome new members
* (Re-)review of actions from last F2F [http://www.tei-c.org/Activities/Council/Meetings/tcm63.xml#actions]
* Update on [https://sourceforge.net/p/tei/feature-requests/510/ correspDesc proposal] (PWS)
* Update on TEI Simple (JC)
* Update on [https://sourceforge.net/p/tei/feature-requests/505/ redefining msPart] (SG / PWS)
* Dates/times for teleconferences
* Date of next release/release technician
* Date/venue for next F2F
* add additional items!

Council

2015-01-24T17:03:37Z

Hcayless: /* Meetings */

The TEI Technical Council, often referred to as 'TEI Council' or 'Council', is the elected body that is responsible for maintaining and implementing the TEI Guidelines. See the [http://www.tei-c.org/Activities/Council/ Council section of the TEI-C website] for archived documents, and [[TEI-Council-FAQ]] for a Council FAQ. The TEI Council also uses this page to store some of its draft agendas and creates pages in the [[:Category: Council|category reserved for use by TEI Council]].

== Meetings ==

See the [[Council-Meeting-Checklist|checklist for organizing a face-to-face meeting]].

{| border="1"
! Meeting date and place
! Agenda
! Minutes
! Action items
|-
|2015-01-30 Teleconference
|[[Council agenda 2015-01]]
|final minutes
|
|-
|2014-12-05 Teleconference
|[[Council agenda 2014-12]]
|final minutes
|
|-
|2014-11-17/18/19 Face to Face in Durham, NC, USA
|[[Council agenda 2014-11]]
|[https://docs.google.com/document/d/16WVX4FEH5EfLJxY3bwlYD_9EBVP5ucS2e_QiOV9mxew/edit?usp=sharing draft minutes], final minutes
|
|-
|2014-10-03 Teleconference
|[[Council agenda 2014-10]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm62.xml final minutes]
|
|-
|2014-08-01 Teleconference
|[[Council agenda 2014-08]]
||[http://www.tei-c.org/Activities/Council/Meetings/tcm61.xml final minutes]

|
|-
|2014-06-30/07-02 Face to Face in Oxford
|[[Council agenda 2014-06]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm60.xml final minutes]
| (in minutes)
|-
|2014-05-30 Teleconference
|[[Council agenda 2014-05]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm59.xml final minutes]
| (in minutes)
|-
|2014-03-07 Teleconference
|[[Council agenda 2014-03]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm58.xml final minutes]
| (in minutes)
|-
|2014-01-10 Teleconference
|[[Council agenda 2014-01]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm57.xml final minutes]
|
|-
|2013-11-11 to 2013-11-13 face-to-face Oxford
|[[Council agenda 2013-11]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm56.xml final minutes]
|[[Oxford2013-Actions2]]
|-
|2013-10-21 Teleconference
|[[Council agenda 2013-10]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm55.xml final minutes]
|
|-
|2013-04-11 to 2013-04-13 face-to-face Providence
|[[Council agenda 2013-04]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm54.xml final minutes]
|[[Council actions 2013-04]]
|-
| 2012-12-13 teleconference
| [[Council agenda 2012-12]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm53.xml final minutes]
|
|-
| 2012-09-19 to 2012-09-21 face-to-face meeting Oxford
| [[Council agenda 2012-09]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm52.xml final minutes]
| [[Oxford2012-Actions]]
|-
| 2012-08-09 teleconference
| [[Council agenda 2012-08]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm51.xml final minutes]
|
|-
| 2012-04-15 to 2012-04-18 face-to-face meeting Ann Arbor
| [[Council agenda 2012-04]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm50.xml final minutes]
| [[AnnArbor2012-Actions]]
|-
| 2012-02-28 Teleconference
| [[Council agenda 2012-02]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm49.xml final minutes]
|
|-
| 2011-11-07 to 2011-11-09 face-to-face meeting Paris
| [[Council agenda 2011-11]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm48.xml final minutes]
|
|-
| 2011-08-17 teleconference
|
| [http://www.tei-c.org/Activities/Council/Meetings/tcm47.xml final minutes]
|
|-
| 2011-04-11 to 2011-04-13 face-to-face meeting Chicago
| [[Council agenda 2011-04]]
| [[Council notes 2011-04]], [http://www.tei-c.org/Activities/Council/Meetings/tcm46.xml final minutes]
|
|-
| 2010-10 feature request assignments
| colspan="3" align="center" | [[Council FR assignments]]
|-
| 2010-04-28 to 2010-04-30 face-to-face meeting Dublin
| [[Council agenda 2010-04]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm45.xml final minutes]
|
|-
| 2010-02-08 teleconference
|
| [http://www.tei-c.org/Activities/Council/Meetings/tcm44.xml final minutes]
|
|-
| 2009-12-07 teleconference
|
| [http://www.tei-c.org/Activities/Council/Meetings/tcm43.xml final minutes]
|
|-
| 2009-10-13 teleconference
| [[Council agenda 2009-10]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm42.xml final minutes]
|
|-
| 2009-04-01 to 2009-04-03 face-to-face meeting Lyon
| [[Council 2009-04]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm41.xml final minutes]
|
|-
| 2008-10-07 teleconference
| [[Council agenda 2008-10]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm40.xml final minutes]
|
|-
| colspan="4" align="center" | For minutes of previous meetings, see [http://www.tei-c.org/Activities/Council/Meetings/ minutes on TEI-C website]
|}

== Workgroups ==

A [http://www.tei-c.org/Activities/Workgroups/index.xml full list is on the TEI-C website] and the following wiki pages:

* [[Ad-hoc committee on encoding of bibliographic citations]]
* [[Text Directionality Workgroup]]

== Old notes ==

=== Item for further consideration ===
* Stable URIs to discrete bits of the guidelines

=== Issues for next F2F ===

* Discussion on ODD and its evolution--[[User:Romary|Romary]] 02:34, 9 September 2008 (EDT)

cf. @usage in elementSpec

ODD modifing an ODD (ODD architecture)

Namespaces

* Evolution of Roma

Proposal (SR): rewriting Roma almost entirely in Javascript, interacting with web services to deliver TEI and to generate outputs. The Javascript would grab a copy of TEI (cut down) from a chosen server, and load it into memory. Then it would use that to help you build your ODD. when you were done, it would send the ODD document to a web service whose job is to return a schema or documentation back to the browsers. So Roma would be a Javascript ODD editor, not needing server support beyond a simple Apache, but closely coupled to a pair of generic web services. The generator web service would be identical code to the Vesta desktop

Additional functionalities needed (PB):

- adding copy element functionality,

- supporting the creation/manipulation of content models (instead of the user having to write the models),

- support/help in creating schematron constraints?

- TEI schema validation service (cf. also ISO project)

* should the TEI-C we produce a general purpose online service which can validate and process documents (cf. ISO work)

=== Highlights to be brought to the TEI MM 2008 ===

=== Topics (could be moved up to one F2F or Telco meeting ===

* Stable reference to TEI objects

(For original source of these comments, see tei-council thread [http://lists.village.virginia.edu/pipermail/tei-council/2008/010041.html Quoting a TEI Object] from September 2008. DS has created a new wiki page for discussing [[Council:stable references|stable references]].)

[LR] In many cases, one has to map schemas and describe the mappings by reference to actual objects in the respective encoding schemes. In this context do (should) we have a mechanism to refer uniquely to TEI objects, beyond the reference to the TEI namespace (<author> in http://www.tei-c.org/ns/1.0), sort of TEI unique identifiers?

[JC] I'd think the proper way to cite an element, class, or datatype generally is to point to its reference page. http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-tree.html

However, we might want to re-examine that... while the hierarchy should remain the same, deprecated elements (etc.) disappear. I have no way easy way to point to something at a particular date in time...unless maybe I point to it at a particular revision in the SVN source tree?

Pointing to a location in the SVN source tree isn't necessarily very pretty but does work and is accurate:

See for example an earlier version of <event>: http://tei.svn.sourceforge.net/viewvc/tei/trunk/P5/Source/Specs/event.xml?revision=231&view=markup

As a cognate example, I can point to any revision of a page in the TEI wiki at any point in its history. We should be able to do this, somehow, in the official way we are meant to cite TEI sources as changing objects in time.

However, maybe an easier solution is to cite:
http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-event.html
but on the generated reference pages like this contain a link to the appropriate place in the SVN repository? i.e.
http://tei.svn.sourceforge.net/viewvc/tei/trunk/P5/Source/Specs/event.xml?view=log
which lists all the revisions.

[AC] The only place on the website where I am ware there are some recommendations with URLs is the citation page:
http://www.tei-c.org/Guidelines/access.xml

This could certainly be enriched with notes on how to point to an element on the line James suggests, but in that case would the version number be enough to point to particular revisions?

[DS] As an alternative to using a TEI-specific convention for citing URLs, we
might want to consider adopting one or another of the standard systems
for permanent identifiers, for example DOI (Digital Object Identifier).

In the case of DOI, there would be some fairly minimal costs involved to
register the DOIs with one of the national registries, but some more
extensive costs in human time to set up a good system for mapping from
our existing nomenclature to a set of DOI identifiers. (Publishers
typically use DOIs to identify individual books or journal articles, but
they can be more granular: every reference page in the Guidelines could
have its own DOI, for example.)

The advantage of doing this would be that anyone accustomed to using
DOIs for citations could simply cite a DOI. So instead of the reference
for <name> in the Guidelines

http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-name.html

we would use something like

doi:10.1111/tei-p5-doc:en:ref-name

which would be resolved to the actual Web address by a DOI resolver.
(Many journal DOIs are mostly numeric but the syntax allows more
human-readable names).

If we seriously want to consider an option like this, we should put out
a call to the librarians/metadata gurus in our community for assistance
with implementation.

[[Category:Council]]

Council agenda 2015-01

2015-01-24T16:41:45Z

Hcayless: Created page with "== Teleconference 2015-01-30 14:00 GMT == * Welcome new members * (Re-)review of actions from last F2F [http://www.tei-c.org/Activities/Council/Meetings/tcm63.xml#actions] * Upd..."

== Teleconference 2015-01-30 14:00 GMT ==

* Welcome new members
* (Re-)review of actions from last F2F [http://www.tei-c.org/Activities/Council/Meetings/tcm63.xml#actions]
* Update on [https://sourceforge.net/p/tei/feature-requests/510/ correspDesc proposal] (PWS)
* Update on [https://sourceforge.net/p/tei/feature-requests/378/ standoff proposal] (PWS)
* Update on [https://sourceforge.net/p/tei/feature-requests/505/ redefining msPart] (SG / PWS)
* Dates/times for teleconferences
* Date of next release/release technician
* Date/venue for next F2F
* add additional items!

Council

2014-11-17T15:49:31Z

Hcayless: /* Meetings */

The TEI Technical Council, often referred to as 'TEI Council' or 'Council', is the elected body that is responsible for maintaining and implementing the TEI Guidelines. See the [http://www.tei-c.org/Activities/Council/ Council section of the TEI-C website] for archived documents, and [[TEI-Council-FAQ]] for a Council FAQ. The TEI Council also uses this page to store some of its draft agendas and creates pages in the [[:Category: Council|category reserved for use by TEI Council]].

== Meetings ==

See the [[Council-Meeting-Checklist|checklist for organizing a face-to-face meeting]].

{| border="1"
! Meeting date and place
! Agenda
! Minutes
! Action items
|-
|2014-11-17/18/19 Face to Face in Durham, NC, USA
|[[Council agenda 2014-11]]
|final minutes
|
|-
|2014-10-03 Teleconference
|[[Council agenda 2014-10]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm62.xml final minutes]
|
|-
|2014-08-01 Teleconference
|[[Council agenda 2014-08]]
||[http://www.tei-c.org/Activities/Council/Meetings/tcm61.xml final minutes]

|
|-
|2014-06-30/07-02 Face to Face in Oxford
|[[Council agenda 2014-06]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm60.xml final minutes]
| (in minutes)
|-
|2014-05-30 Teleconference
|[[Council agenda 2014-05]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm59.xml final minutes]
| (in minutes)
|-
|2014-03-07 Teleconference
|[[Council agenda 2014-03]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm58.xml final minutes]
| (in minutes)
|-
|2014-01-10 Teleconference
|[[Council agenda 2014-01]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm57.xml final minutes]
|
|-
|2013-11-11 to 2013-11-13 face-to-face Oxford
|[[Council agenda 2013-11]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm56.xml final minutes]
|[[Oxford2013-Actions2]]
|-
|2013-10-21 Teleconference
|[[Council agenda 2013-10]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm55.xml final minutes]
|
|-
|2013-04-11 to 2013-04-13 face-to-face Providence
|[[Council agenda 2013-04]]
|[http://www.tei-c.org/Activities/Council/Meetings/tcm54.xml final minutes]
|[[Council actions 2013-04]]
|-
| 2012-12-13 teleconference
| [[Council agenda 2012-12]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm53.xml final minutes]
|
|-
| 2012-09-19 to 2012-09-21 face-to-face meeting Oxford
| [[Council agenda 2012-09]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm52.xml final minutes]
| [[Oxford2012-Actions]]
|-
| 2012-08-09 teleconference
| [[Council agenda 2012-08]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm51.xml final minutes]
|
|-
| 2012-04-15 to 2012-04-18 face-to-face meeting Ann Arbor
| [[Council agenda 2012-04]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm50.xml final minutes]
| [[AnnArbor2012-Actions]]
|-
| 2012-02-28 Teleconference
| [[Council agenda 2012-02]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm49.xml final minutes]
|
|-
| 2011-11-07 to 2011-11-09 face-to-face meeting Paris
| [[Council agenda 2011-11]]
| [[Paris 2011-11 minutes|draft minutes]], [http://www.tei-c.org/Activities/Council/Meetings/tcm48.xml final minutes]
|
|-
| 2011-08-17 teleconference
|
| [http://www.tei-c.org/Activities/Council/Meetings/tcm47.xml final minutes]
|
|-
| 2011-04-11 to 2011-04-13 face-to-face meeting Chicago
| [[Council agenda 2011-04]]
| [[Council notes 2011-04]], [http://www.tei-c.org/Activities/Council/Meetings/tcm46.xml final minutes]
|
|-
| 2010-10 feature request assignments
| colspan="3" align="center" | [[Council FR assignments]]
|-
| 2010-04-28 to 2010-04-30 face-to-face meeting Dublin
| [[Council agenda 2010-04]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm45.xml final minutes]
|
|-
| 2010-02-08 teleconference
|
| [http://www.tei-c.org/Activities/Council/Meetings/tcm44.xml final minutes]
|
|-
| 2009-12-07 teleconference
|
| [http://www.tei-c.org/Activities/Council/Meetings/tcm43.xml final minutes]
|
|-
| 2009-10-13 teleconference
| [[Council agenda 2009-10]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm42.xml final minutes]
|
|-
| 2009-04-01 to 2009-04-03 face-to-face meeting Lyon
| [[Council 2009-04]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm41.xml final minutes]
|
|-
| 2008-10-07 teleconference
| [[Council agenda 2008-10]]
| [http://www.tei-c.org/Activities/Council/Meetings/tcm40.xml final minutes]
|
|-
| colspan="4" align="center" | For minutes of previous meetings, see [http://www.tei-c.org/Activities/Council/Meetings/ minutes on TEI-C website]
|}

== Workgroups ==

A [http://www.tei-c.org/Activities/Workgroups/index.xml full list is on the TEI-C website] and the following wiki pages:

* [[Ad-hoc committee on encoding of bibliographic citations]]
* [[Text Directionality Workgroup]]

== Old notes ==

=== Item for further consideration ===
* Stable URIs to discrete bits of the guidelines

=== Issues for next F2F ===

* Discussion on ODD and its evolution--[[User:Romary|Romary]] 02:34, 9 September 2008 (EDT)

cf. @usage in elementSpec

ODD modifing an ODD (ODD architecture)

Namespaces

* Evolution of Roma

Proposal (SR): rewriting Roma almost entirely in Javascript, interacting with web services to deliver TEI and to generate outputs. The Javascript would grab a copy of TEI (cut down) from a chosen server, and load it into memory. Then it would use that to help you build your ODD. when you were done, it would send the ODD document to a web service whose job is to return a schema or documentation back to the browsers. So Roma would be a Javascript ODD editor, not needing server support beyond a simple Apache, but closely coupled to a pair of generic web services. The generator web service would be identical code to the Vesta desktop

Additional functionalities needed (PB):

- adding copy element functionality,

- supporting the creation/manipulation of content models (instead of the user having to write the models),

- support/help in creating schematron constraints?

- TEI schema validation service (cf. also ISO project)

* should the TEI-C we produce a general purpose online service which can validate and process documents (cf. ISO work)

=== Highlights to be brought to the TEI MM 2008 ===

=== Topics (could be moved up to one F2F or Telco meeting ===

* Stable reference to TEI objects

(For original source of these comments, see tei-council thread [http://lists.village.virginia.edu/pipermail/tei-council/2008/010041.html Quoting a TEI Object] from September 2008. DS has created a new wiki page for discussing [[Council:stable references|stable references]].)

[LR] In many cases, one has to map schemas and describe the mappings by reference to actual objects in the respective encoding schemes. In this context do (should) we have a mechanism to refer uniquely to TEI objects, beyond the reference to the TEI namespace (<author> in http://www.tei-c.org/ns/1.0), sort of TEI unique identifiers?

[JC] I'd think the proper way to cite an element, class, or datatype generally is to point to its reference page. http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-tree.html

However, we might want to re-examine that... while the hierarchy should remain the same, deprecated elements (etc.) disappear. I have no way easy way to point to something at a particular date in time...unless maybe I point to it at a particular revision in the SVN source tree?

Pointing to a location in the SVN source tree isn't necessarily very pretty but does work and is accurate:

See for example an earlier version of <event>: http://tei.svn.sourceforge.net/viewvc/tei/trunk/P5/Source/Specs/event.xml?revision=231&view=markup

As a cognate example, I can point to any revision of a page in the TEI wiki at any point in its history. We should be able to do this, somehow, in the official way we are meant to cite TEI sources as changing objects in time.

However, maybe an easier solution is to cite:
http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-event.html
but on the generated reference pages like this contain a link to the appropriate place in the SVN repository? i.e.
http://tei.svn.sourceforge.net/viewvc/tei/trunk/P5/Source/Specs/event.xml?view=log
which lists all the revisions.

[AC] The only place on the website where I am ware there are some recommendations with URLs is the citation page:
http://www.tei-c.org/Guidelines/access.xml

This could certainly be enriched with notes on how to point to an element on the line James suggests, but in that case would the version number be enough to point to particular revisions?

[DS] As an alternative to using a TEI-specific convention for citing URLs, we
might want to consider adopting one or another of the standard systems
for permanent identifiers, for example DOI (Digital Object Identifier).

In the case of DOI, there would be some fairly minimal costs involved to
register the DOIs with one of the national registries, but some more
extensive costs in human time to set up a good system for mapping from
our existing nomenclature to a set of DOI identifiers. (Publishers
typically use DOIs to identify individual books or journal articles, but
they can be more granular: every reference page in the Guidelines could
have its own DOI, for example.)

The advantage of doing this would be that anyone accustomed to using
DOIs for citations could simply cite a DOI. So instead of the reference
for <name> in the Guidelines

http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-name.html

we would use something like

doi:10.1111/tei-p5-doc:en:ref-name

which would be resolved to the actual Web address by a DOI resolver.
(Many journal DOIs are mostly numeric but the syntax allows more
human-readable names).

If we seriously want to consider an option like this, we should put out
a call to the librarians/metadata gurus in our community for assistance
with implementation.

[[Category:Council]]

Council agenda 2014-11

2014-11-14T19:55:17Z

Hcayless: /* Wednesday 19 November 2014 */

=Draft Agenda for TEI Technical Council Meeting 2014-11-17 to 2014-11-19=

== Monday 17 November 2014 ==
09:00 - 10:30
* TEI Simple
* Pure ODD
* TEI DH2015 HackAThon
* Correspondence
10:30 - 10:45
* Tea Break
10:45 - 13:00
* Ticket Discussion and Assignment
13:00 - 14:30
* Lunch
14:30 - 16:00 (15:30 - Tea Break)
* Tickets Recap and other discussion
16:00 - 17:00
* Ticket implementation or other TEI Work
18:00- Dinner at Josh Sosin's house. HC will pick up from the hotel at 18:15

== Tuesday 18 November 2014 ==
09:00 - 10:30
* JTEI Schema and authoring package: should the schema be adopted as an "official" customization, and should the authoring package be integrated into the oxygen-tei plugin? (MH)
* Global @resp and friends (MH, LB, HC)
* LOC date attrs (SB; see [http://loc.gov/standards/datetime/pre-submission.html LOC draft standard])
10:30 - 10:45
* Tea Break
10:45 - 13:00
* Tickets
13:00 - 14:00
* Lunch ?
14:00 - 17:00
* Tickets Discussion
18:00-
* DInner @ 19:00? Possibilities include Dos Perros (http://dosperrosrestaurant.com/); Bull City Burger and Brewery (http://www.bullcityburgerandbrewery.com/Bull_City_Burger_and_Brewery/Home.html); many others

== Wednesday 19 November 2014 ==
09:00 - 10:30
* Presentation on how OxGarage works (JC)
* Critical Apparatus proposal update (HC)
10:30 - 10:45
* Tea Break
10:45 - 13:00
* Ticket Discussion and Assignment
13:10 - 14:30
* Lunch (?)
14:30 - 15:30
* Tickets Recap and other discussion
15:30
* tea break
15:30 - 17:00
* Ticket implementation or other TEI Work
18:00 -
*

[[Category:Council]]

Council agenda 2014-11

2014-11-14T19:54:22Z

Hcayless: /* Tuesday 18 November 2014 */

=Draft Agenda for TEI Technical Council Meeting 2014-11-17 to 2014-11-19=

== Monday 17 November 2014 ==
09:00 - 10:30
* TEI Simple
* Pure ODD
* TEI DH2015 HackAThon
* Correspondence
10:30 - 10:45
* Tea Break
10:45 - 13:00
* Ticket Discussion and Assignment
13:00 - 14:30
* Lunch
14:30 - 16:00 (15:30 - Tea Break)
* Tickets Recap and other discussion
16:00 - 17:00
* Ticket implementation or other TEI Work
18:00- Dinner at Josh Sosin's house. HC will pick up from the hotel at 18:15

== Tuesday 18 November 2014 ==
09:00 - 10:30
* JTEI Schema and authoring package: should the schema be adopted as an "official" customization, and should the authoring package be integrated into the oxygen-tei plugin? (MH)
* Global @resp and friends (MH, LB, HC)
* LOC date attrs (SB; see [http://loc.gov/standards/datetime/pre-submission.html LOC draft standard])
10:30 - 10:45
* Tea Break
10:45 - 13:00
* Tickets
13:00 - 14:00
* Lunch ?
14:00 - 17:00
* Tickets Discussion
18:00-
* DInner @ 19:00? Possibilities include Dos Perros (http://dosperrosrestaurant.com/); Bull City Burger and Brewery (http://www.bullcityburgerandbrewery.com/Bull_City_Burger_and_Brewery/Home.html); many others

== Wednesday 19 November 2014 ==
09:00 - 10:30
* Presentation on how OxGarage works (JC)
10:30 - 10:45
* Tea Break
10:45 - 13:00
* Ticket Discussion and Assignment
13:10 - 14:30
* Lunch (?)
14:30 - 15:30
* Tickets Recap and other discussion
15:30
* tea break
15:30 - 17:00
* Ticket implementation or other TEI Work
18:00 -
*

[[Category:Council]]

Council agenda 2014-11

2014-11-14T19:53:54Z

Hcayless: /* Wednesday 19 November 2014 */

=Draft Agenda for TEI Technical Council Meeting 2014-11-17 to 2014-11-19=

== Monday 17 November 2014 ==
09:00 - 10:30
* TEI Simple
* Pure ODD
* TEI DH2015 HackAThon
* Correspondence
10:30 - 10:45
* Tea Break
10:45 - 13:00
* Ticket Discussion and Assignment
13:00 - 14:30
* Lunch
14:30 - 16:00 (15:30 - Tea Break)
* Tickets Recap and other discussion
16:00 - 17:00
* Ticket implementation or other TEI Work
18:00- Dinner at Josh Sosin's house. HC will pick up from the hotel at 18:15

== Tuesday 18 November 2014 ==
09:00 - 10:30
* JTEI Schema and authoring package: should the schema be adopted as an "official" customization, and should the authoring package be integrated into the oxygen-tei plugin? (MH)
* Global @resp and friends (MH, LB, HC)
* LOC date attrs (SB; see [http://loc.gov/standards/datetime/pre-submission.html LOC draft standard])
10:30 - 10:45
* Tea Break
10:45 - 13:00
* Tickets
13:00 - 14:00
* Lunch ?
14:00 - 17:00
* Tickets Discussion
18:00-
* ??

== Wednesday 19 November 2014 ==
09:00 - 10:30
* Presentation on how OxGarage works (JC)
10:30 - 10:45
* Tea Break
10:45 - 13:00
* Ticket Discussion and Assignment
13:10 - 14:30
* Lunch (?)
14:30 - 15:30
* Tickets Recap and other discussion
15:30
* tea break
15:30 - 17:00
* Ticket implementation or other TEI Work
18:00 -
*

[[Category:Council]]

Council agenda 2014-11

2014-11-14T19:53:33Z

Hcayless: /* Wednesday 19 November 2014 */

=Draft Agenda for TEI Technical Council Meeting 2014-11-17 to 2014-11-19=

== Monday 17 November 2014 ==
09:00 - 10:30
* TEI Simple
* Pure ODD
* TEI DH2015 HackAThon
* Correspondence
10:30 - 10:45
* Tea Break
10:45 - 13:00
* Ticket Discussion and Assignment
13:00 - 14:30
* Lunch
14:30 - 16:00 (15:30 - Tea Break)
* Tickets Recap and other discussion
16:00 - 17:00
* Ticket implementation or other TEI Work
18:00- Dinner at Josh Sosin's house. HC will pick up from the hotel at 18:15

== Tuesday 18 November 2014 ==
09:00 - 10:30
* JTEI Schema and authoring package: should the schema be adopted as an "official" customization, and should the authoring package be integrated into the oxygen-tei plugin? (MH)
* Global @resp and friends (MH, LB, HC)
* LOC date attrs (SB; see [http://loc.gov/standards/datetime/pre-submission.html LOC draft standard])
10:30 - 10:45
* Tea Break
10:45 - 13:00
* Tickets
13:00 - 14:00
* Lunch ?
14:00 - 17:00
* Tickets Discussion
18:00-
* ??

== Wednesday 19 November 2014 ==
09:00 - 10:30
* Presentation on how OxGarage works (JC)
10:30 - 10:45
* Tea Break
10:45 - 13:00
* Ticket Discussion and Assignment
13:10 - 14:30
* Lunch (?)
14:30 - 15:30
* Tickets Recap and other discussion
15:30
* tea break
15:30 - 17:00
* Ticket implementation or other TEI Work
18:00 -
* DInner @ 19:00? Possibilities include Dos Perros (http://dosperrosrestaurant.com/); Bull City Burger and Brewery (http://www.bullcityburgerandbrewery.com/Bull_City_Burger_and_Brewery/Home.html); many others

[[Category:Council]]

Council agenda 2014-11

2014-11-14T19:44:19Z

Hcayless: /* Monday 17 November 2014 */

=Draft Agenda for TEI Technical Council Meeting 2014-11-17 to 2014-11-19=

== Monday 17 November 2014 ==
09:00 - 10:30
* TEI Simple
* Pure ODD
* TEI DH2015 HackAThon
* Correspondence
10:30 - 10:45
* Tea Break
10:45 - 13:00
* Ticket Discussion and Assignment
13:00 - 14:30
* Lunch
14:30 - 16:00 (15:30 - Tea Break)
* Tickets Recap and other discussion
16:00 - 17:00
* Ticket implementation or other TEI Work
18:00- Dinner at Josh Sosin's house. HC will pick up from the hotel at 18:15

== Tuesday 18 November 2014 ==
09:00 - 10:30
* JTEI Schema and authoring package: should the schema be adopted as an "official" customization, and should the authoring package be integrated into the oxygen-tei plugin? (MH)
* Global @resp and friends (MH, LB, HC)
* LOC date attrs (SB; see [http://loc.gov/standards/datetime/pre-submission.html LOC draft standard])
10:30 - 10:45
* Tea Break
10:45 - 13:00
* Tickets
13:00 - 14:00
* Lunch ?
14:00 - 17:00
* Tickets Discussion
18:00-
* ??

== Wednesday 19 November 2014 ==
09:00 - 10:30
* Presentation on how OxGarage works (JC)
10:30 - 10:45
* Tea Break
10:45 - 13:00
* Ticket Discussion and Assignment
13:10 - 14:30
* Lunch (?)
14:30 - 15:30
* Tickets Recap and other discussion
15:30
* tea break
15:30 - 17:00
* Ticket implementation or other TEI Work
18:00 -
* ??

[[Category:Council]]

Global @resp attribute

2014-11-13T21:32:24Z

Hcayless: /* PERIPHERAL ISSUE: @source */

===Proposal for a Global @resp attribute===

This page summarizes the discussions of LB, HC and MH on [http://sourceforge.net/p/tei/feature-requests/443/Feature request 443].

==THE PROBLEM PART 1: @resp==

Many, many users want to use @resp all over the place; but the current meaning of @resp is already confusingly dependent on its context:

@resp: "(responsible party) indicates the agency responsible for the intervention or interpretation, for example an editor or transcriber."

In the Glines, we have examples of @resp use to express responsibility for:

*editorial interventions such as <corr>, <ex>, <supplied>
*specifying a <spanGrp> or <interpGrp>
*writing a <note>
*identifying a <persName> as such
*specifying the place and date of someone's birth (<event>)
*counting the populations of red and grey squirrels between specific dates (<population>)
*providing supplementary info about a witness (<witDetail>)
*writing an abstract (<abstract>)
*describing the origin of a MS (<origin>)
*the entire act of transcribing and encoding a passage (<respons>)

and many more things. Sometimes @resp refers to manipulating text in an editorial capacity; sometimes to making judgements and applying markup; and sometimes to providing information or explanation.

There is clearly a need to allow people to use @resp globally. Since our own Glines show examples of it to describe the complete act of transcribing and encoding, it makes no sense to limit its context such that it could not be used for any of the component elements of an encoded text; and since we already have examples of its use in the header, there is no reason to exclude that either. Since there are examples of its use to specify responsibility for the selection and application of a TEI tag, there is no reason to prevent a user from assigning responsibility for the application of any TEI tag; ergo the attribute should be global.

The problem of what @resp refers to in any specific context remains, but the examples from the <respons> spec provide a straightforward solution: rather than pointing directly to an agent, @resp should point to a <respStmt>, in which the nature of the responsibility is clear in the <resp>(s).

==THE PROBLEM PART 2: @cert==

att.responsibility also contains @cert. Should this also be global?

Given that whenever we assign responsibility for something to an agent, there is always the possibility that we are not certain about it, then there is no context in which @resp could be used without the possible need for @cert. Therefore @cert should also be global.

The solution:

# Promote att.responsibility to att.global.responsibility, and make it a member of att.global.
# Add a note to @resp recommending that wherever possible it point not directly to an agent but to a <respStmt>.
# Add several examples to the att.responsibility specification showing a variety of uses of @resp pointing to <respStmt>.
# Update all references to att.responsibility in the Glines prose (e.g. in Names and Dates, we have "Some members of the att.naming class are also members of the att.responsibility class, from which they inherit the following attributes..."
# Look at all chapter sections which address the use of att.[global.]responsibility attributes and make any required changes, including suggesting that @resp point at <respStmt> where this is appropriate. This includes Chapters 3, 13, and 17.
# Expand 21.3 (http://www.tei-c.org/release/doc/tei-p5-doc/en/html/CE.html#CERESP), "Attribution of responsibility", so that it also mentions the use of @resp as a simpler alternative to a full <respons> element.

==PERIPHERAL ISSUE: @source==

We have had some discussions about whether it makes sense for @source to be global along with @resp and @cert. This is based on the notion that, if you're assigning responsibility to someone for something, and expressing some uncertainty about it, you may well wish to say on what source you're basing the assertion. We disagree about the need for this.

HC contends that in any place one might want to indicate an intellectual contribution by an editor/encoder of the document, one might equally well want to cite an external authority for that contribution. HC also feels @source has a stronger argument for universality than @cert.

Council agenda 2014-05

2014-05-30T12:15:54Z

Hcayless:

==Council Agenda for 2014-05-30 teleconference ==

# Report on upcoming face-to-face (JC)
# Report on autumn face-to-face (HC)
# Report on TEI Simple (SR)
# Report on TEI Hackathon (EM)
# Report on TEI Conference (JC)
# Object Working Group
# Next Release
# TEI Pointers (more or less) final draft (HC)
# Add items here

[[Category:Council]]

Oxford2013-Actions2

2014-01-10T12:50:11Z

Hcayless: /* Actions for Hugh Cayless */

==Council Actions from November 2013 Oxford Meeting==

A list of actions, those responsible, and what has been done about them from [http://www.tei-c.org/Activities/Council/Meetings/tcm56.xml Oxford 2013 face to face meeting] of TEI Technical Council

===Actions for Brett Barney===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|Attributes without examples

|BB, RW
|BB and RW to turn into bug reports those attributes that are without examples that are high priority or need new/updated definitions.
|
|-
|[https://sourceforge.net/p/tei/bugs/563/ BUG 563] inconsistent encoding of citations to sources of examples (AMBER open). Working group recommends ass...
|BB, EM, PS
|BB, EM, and PS to work on the ticket by mid-February 2014.
|
|-
|[https://sourceforge.net/p/tei/bugs/610/ BUG 610] "lem" used in a confusing way in CriticalApparatus.xml (AMBER open). Action: BB to remove the last c...
|BB
|BB to remove the last clause of the sentence in question, beginning ", or to make clear".
|Done 2013-11-13
|-
|[https://sourceforge.net/p/tei/bugs/387/ BUG 387] clarifying heading or title of a graphic (GREEN open). LB recently posted a comment approving of the...
|BB
|BB will implement the ticket.
|Done 2013-11-13
|}

===Actions for Lou Burnard===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|[https://sourceforge.net/p/tei/feature-requests/457/ FR 457] : KH: In the ticket I want to clarify what you use tagUsage for and what to put in a project-specifi...
|KH, LB, JC
|KH, LB, and JC will review and make a recommendation to Council before the next face-to-face.
|KH emailed the others on 2013-12-26; LB updated ticket and emailed the others 2014-01-05
|-
|[https://sourceforge.net/p/tei/feature-requests/453/ FR 453] a place for metadata that you can't fit into existing header elements AMBER open Discussion talks mo...
|MH, PS, LB
|MH will offer DC examples and PS will offer MARC examples. LB will pull them together into some text to be inserted into the Guidelines. Given this, Council will reconsider the feature request and whether to create the wrapper element.
|Added comment on ticket suggesting that the proposal seems doomed to be rejected; action to explain how to handle this situation in the Guidelines remains open.
|-
|[https://sourceforge.net/p/tei/feature-requests/471/ FR 471] extend the possible usages of argument (AMBER open). (If the intended use case is encoder-supplied a...
|LB, MH
|New element <abstract> added; examples added .
|Done 2013-11-12
|-
|Pure ODD

|LB
|LB to add the new elements and the documentation ahead of the next release; documentation need only be at the element level, along with some brief introduction in the Guidelines, to be expanded to a full section later.
|First pass completed 2013-12-01
|-
|[https://sourceforge.net/p/tei/feature-requests/443/ FR 443] @resp should be a member of att.global AMBER open. JC and SR: Global attributes should really not be...
|MH, LB
|MH and LB to agree on clarification to Guidelines to say that @resp means different things: responsibility for markup and content except when the element in question is a transcriptional element, in which case the content of the element is marked as coming from the source.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/366/ FR 366] rationalize content models of org and place (etc) (AMBER open). Group thinks a small group of people...
|JC, LB, SB
|JC to make ticket red, should stay with JC, and he should initiate the process, working with LB and SB.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/458/ FR 458] Make listBibl and model.biblLike member of model.personPart (AMBER open). Lou has already done items...
|LB
|close the ticket.
|Done
|-
|i18n: take forward updating translations

|LB
|LB to testdrive the spreadsheet.
|Done
|-
|[https://sourceforge.net/p/tei/feature-requests/482/ FR 482] The term strikes back - terminology chapter (AMBER open). The ISO is working on a standard for termi...
|LB, KH, SB
|LB, KH and SB to articulate a more generic policy for TEI on the integration of external standards and will generate a one-page proposal for this policy. This should be provided to Council ahead of the next teleconference. In addition, LB, KH, and SB will check with Laurent that he wants TBX incorporated into the Guidelines as is or kept in sync in the future and what he thinks about melding into the rest of the TEI Guidelines (in language, approach, element naming conventions) or keeping it self-contained.
|Kevin drafted a [http://www.tei-c.org/Activities/Council/Working/tcw28.xml generic policy] and circulated to Lou and Syd on 2013-12-26. Discussion of whether to incorporate TBX into the Guidelines is [http://sourceforge.net/p/tei/feature-requests/482/#28f3 happening on ticket].
|-
|[https://sourceforge.net/p/tei/feature-requests/480/ FR 480] Adding the @hand attribute to all (or most) text-containing elements (AMBER open). Breakout group wa...
|LB
|LB to respond to the ticket FR 480.
|
|-
|[http://wiki.tei-c.org/index.php/Text_Directionality_Draft first draft of new Guidelines sections] and questions [MH] MH summarized the genesis of this text from Providence. He noted that not only th...
|MH, LB
|Entire Council to (re)read MH’s draft before next face-to-face meeting. Once we’ve done that and agreed, someone will rewrite chapter 5 (WD) to include MH’s draft and the current section 10.6.6. LB volunteered.
|
|-
|[https://sourceforge.net/p/tei/bugs/548/ BUG 548] use of modal verbs in Guidelines (AMBER pending-later). Already assigned to KH. RW agreed to help. I...
|KH, RW, LB
|KH and RW to create a new, detailed ticket with all questionable cases. In the meantime, LB will fix the edits that KH made at r12525.
|Commented out otiose paragraph.
|-
|[https://sourceforge.net/p/tei/bugs/468/ BUG 468] Order of elements in publicationStmt (AMBER open-accepted). Group discussion: SB: Despite Lou’s comm...
|SB, LB
|SB will do the content model and LB will do the prose. They’ll work out the specifics.
|Emailed syd 2014-01-05
|-
|[https://sourceforge.net/p/tei/feature-requests/469/ FR 469] add extent to att.dimensions (GREEN open). Agreed. Action: LB to provide an example in HD chapter (2...
|LB
|LB to provide an example in HD chapter (2.2.3) and close ticket.
|Done 2013-11-20
|-
|[https://sourceforge.net/p/tei/bugs/605/ BUG 605] clarifying add vs. supplied and del vs. surplus (AMBER open). Action: HC to emend the prose of the p...
|HC, LB
|HC to emend the prose of the paragraph beginning "The add element should not be used" to reference the surplus element also; LB points out that the specList can't be modified, because supplied/surplus aren't defined in Core.
|Done, I think.
|-
|[https://sourceforge.net/p/tei/bugs/609/ BUG 609] "lemma" used in a confusing way in CriticalApparatus.xml (AMBER open). Action: LB to remove the phra...
|LB
|LB to remove the phrase "on any one lemma" from the @varSeq description.
|Done, 2013-11-13
|-
|[https://sourceforge.net/p/tei/feature-requests/461/ FR 461] Two small improvements to `recording` (GREEN open). Action: LB to do this by next teleconference....
|LB
|LB to do this by next teleconference.
|Done 2013-11-13
|-
|[https://sourceforge.net/p/tei/feature-requests/482/ FR 482] Earlier we decided:Action: LB, KH and SB to articulate a more generic policy for TEI on the integrat...
|LB, KH, SB
|LB, KH and SB to articulate a more generic policy for TEI on the integration of external standards and will generate a one-page proposal for this policy. This should be provided to Council ahead of the next teleconference. In addition, LB, KH, and SB will check with Laurent that he wants TBX incorporated into the Guidelines as is or kept in sync in the future and what he thinks about melding into the rest of the TEI Guidelines (in language, approach, element naming conventions) or keeping it self-contained.
|Kevin drafted a [http://www.tei-c.org/Activities/Council/Working/tcw28.xml generic policy] and circulated to Lou and Syd on 2013-12-26. Discussion of whether to incorporate TBX into the Guidelines is [http://sourceforge.net/p/tei/feature-requests/482/#28f3 happening on ticket].
|-
|Correspondence SIG:

|SB, LB
|SB and LB would like to (re?-)join the task force. Council advises them to keep in mind the work by the Ontology/MS SIGs, in particular Torsten Schassan, on an ‘object’ or ‘objectDesc’ element.
|
|}

===Actions for Syd Bauman===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|[https://sourceforge.net/p/tei/feature-requests/384/ FR 384] : In April RW made a spreadsheet showing which elements she recommends moving into att.typed. And in...
|SB, RW
|SB and RW will review the list again.
|SB sent e-mail to RW 2013-12-06, no response yet (2014-01-10)
|-
|[https://sourceforge.net/p/tei/feature-requests/459/ FR 459] : This is just waiting for implementation....
|SB
|SB will implement by end of January 2014.
|SB: if I understand ticket correctly, this was done along w/ 486.
|-
|[https://sourceforge.net/p/tei/feature-requests/481/ FR 481] check that all sibling att.translatable elements have @versionDate (AMBER open). (Agreed that siblin...
|SB
|SB to check whether this is implemented, and if not, get it implemented then close the ticket.
|was not implemented; have written code, but not tested sufficiently or checked-in
|-
|[https://sourceforge.net/p/tei/feature-requests/468/ FR 468] : HC: precision expresses false precision that’s not real probability. It’s something more like cert...
|SB
|
|
|-
|[https://sourceforge.net/p/tei/feature-requests/383/ FR 383] where to put idno within biblStruct? (AMBER open) This is one of three tickets where KH could not fi...
|KH, SB
|KH will create a new ticket pointing to this and the other two tickets with deprecation problems (as listed on the wiki) saying we need a way to deprecate members of content model and reassign to SB to solve the three tickets using a Schematron warning, and to add @validUntil on constraintSpec.
|This ticket reassigned to Syd, and new ticket created: https://sourceforge.net/p/tei/feature-requests/486/ .
|-
|[https://sourceforge.net/p/tei/feature-requests/366/ FR 366] rationalize content models of org and place (etc) (AMBER open). Group thinks a small group of people...
|JC, LB, SB
|JC to make ticket red, should stay with JC, and he should initiate the process, working with LB and SB.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/482/ FR 482] The term strikes back - terminology chapter (AMBER open). The ISO is working on a standard for termi...
|LB, KH, SB
|LB, KH and SB to articulate a more generic policy for TEI on the integration of external standards and will generate a one-page proposal for this policy. This should be provided to Council ahead of the next teleconference. In addition, LB, KH, and SB will check with Laurent that he wants TBX incorporated into the Guidelines as is or kept in sync in the future and what he thinks about melding into the rest of the TEI Guidelines (in language, approach, element naming conventions) or keeping it self-contained.
|Kevin drafted a [http://www.tei-c.org/Activities/Council/Working/tcw28.xml generic policy] and circulated to Lou and Syd on 2013-12-26. Discussion of whether to incorporate TBX into the Guidelines is [http://sourceforge.net/p/tei/feature-requests/482/#28f3 happening on ticket].
|-
|[https://sourceforge.net/p/tei/bugs/276/ BUG 276] internationalisation links (AMBER open). Language links at bottom of a page should take you to same ...
|JC, SB
|JC to make Green and allocate to SB.
|
|-
|[https://sourceforge.net/p/tei/bugs/619/ BUG 619] tei_allPlus.rng: conflicting ID-types for attribute "id" of element "partialdiff" from namespace "ht...
|SB
|SB to double-check whether able to reproduce and report back on ticket if able to.
|
|-
|[https://sourceforge.net/p/tei/bugs/288/ BUG 288] deprecate use of gram except as a child of gramGrp (AMBER open-accepted). [This is pending creation ...
|SB
|SB to create the new ticket and write the Schematron for this particular deprecation.
|Elsewhere we decided that KH would create the new ticket, which he's done at https://sourceforge.net/p/tei/feature-requests/486/ . But SB still needs to solve this ticket.
|-
|[https://sourceforge.net/p/tei/bugs/468/ BUG 468] Order of elements in publicationStmt (AMBER open-accepted). Group discussion: SB: Despite Lou’s comm...
|SB, LB
|SB will do the content model and LB will do the prose. They’ll work out the specifics.
|Content model checked-in w/ typo at r12736, fixed in r12748.
|-
|[https://sourceforge.net/p/tei/bugs/405/ BUG 405] XPointer schemes may not nest, but see ch. 16 (AMBER open). Action: SB to fix documentation....
|SB
|SB to fix documentation.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/482/ FR 482] Earlier we decided:Action: LB, KH and SB to articulate a more generic policy for TEI on the integrat...
|LB, KH, SB
|LB, KH and SB to articulate a more generic policy for TEI on the integration of external standards and will generate a one-page proposal for this policy. This should be provided to Council ahead of the next teleconference. In addition, LB, KH, and SB will check with Laurent that he wants TBX incorporated into the Guidelines as is or kept in sync in the future and what he thinks about melding into the rest of the TEI Guidelines (in language, approach, element naming conventions) or keeping it self-contained.
|Kevin drafted a [http://www.tei-c.org/Activities/Council/Working/tcw28.xml generic policy] and circulated to Lou and Syd on 2013-12-26. Discussion of whether to incorporate TBX into the Guidelines is [http://sourceforge.net/p/tei/feature-requests/482/#28f3 happening on ticket].
|-
|[http://sourceforge.net/p/tei/feature-requests/378/ FR 378] ; c.f. A Generic Formalism for Encoding Standoff annotations in TEI). Action: JC to ask Peter Stadle...
|JC, HC, SB
|JC to ask Peter Stadler if he’d like to attend as Council rep; otherwise any interested members of Council (HC,SB) are encouraged to attend virtually.
|
|-
|Correspondence SIG:

|SB, LB
|SB and LB would like to (re?-)join the task force. Council advises them to keep in mind the work by the Ontology/MS SIGs, in particular Torsten Schassan, on an ‘object’ or ‘objectDesc’ element.
|
|-
|[https://sourceforge.net/p/tei/bugs/525/ BUG 525] citedRange and biblScope should share att class (GREEN open). SB admitted to sloth. Action: SB to co...
|SB
|SB to complete.
|
|}

===Actions for Hugh Cayless===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|Report on specification and estimated cost for XPointer resolver [HC/SB]

|HC
|HC to report on XPointer resolver and whether we should progress it.
|Draft GLs revision posted on [http://hcayless.github.io/TEI-Guidelines/Guidelines-web/en/html/SA.html#SATS GitHub]
|-
|[https://sourceforge.net/p/tei/feature-requests/465/ FR 465] : Gabby and HC seem to agree on it, and the example looks sensible. LB’s comment could be raised as ...
|HC
|HC will implement before end of January 2014.
|Done.
|-
|[https://sourceforge.net/p/tei/feature-requests/384/ FR 384] that once 384 is implemented, we’ll add a note on att.typed reminding people that this is meant for ...
|HC, KH
|HC will implement [DONE]. KH will add a comment to FR 384 [DONE].
|done during Council meeting
|-
|[https://sourceforge.net/p/tei/feature-requests/462/ FR 462] idno@type='uri' for Linked Data AMBER open (We agreed. @type=”URI” alongside @type=”URL”) EM: The su...
|HC
|HC to implement this and close the ticket FR 462.
|Done.
|-
|[https://sourceforge.net/p/tei/feature-requests/468/ FR 468] : HC: precision expresses false precision that’s not real probability. It’s something more like cert...
|HC
|HC to email TEI-L.
|FR implemented at meeting and email sent. No agitated (or indeed, any) responses.
|-
|Ideas on how to run an experimental TEI Hackathon [SR]

|JC, HC, SR, EM
|JC to approach the DH 2014 committee and find out how they would prefer us to do it, and whether it’s a good idea; and tell the Board that HC, SR and EM are prepared to be involved in organizing this along with one or more Board members.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/212/ FR 212] Generic dating class (AMBER pending-accepted). Gabby claimed in 2011 that it’s done except needs som...
|HC, MH
|HC to investigate whether it’s actually been done. MH offered examples if needed.
|Gabby says the element/classSpecs were done, but corresponding prose was never added to the Guidelines. Opened a new bug [https://sourceforge.net/p/tei/bugs/635/ #635] to address that.
|-
|[https://sourceforge.net/p/tei/bugs/605/ BUG 605] clarifying add vs. supplied and del vs. surplus (AMBER open). Action: HC to emend the prose of the p...
|HC, LB
|HC to emend the prose of the paragraph beginning "The add element should not be used" to reference the surplus element also; LB points out that the specList can't be modified, because supplied/surplus aren't defined in Core.
|Done.
|-
|[http://sourceforge.net/p/tei/feature-requests/378/ FR 378] ; c.f. A Generic Formalism for Encoding Standoff annotations in TEI). Action: JC to ask Peter Stadle...
|JC, HC, SB
|JC to ask Peter Stadler if he’d like to attend as Council rep; otherwise any interested members of Council (HC,SB) are encouraged to attend virtually.
|
|}

===Actions for James Cummings===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|[https://sourceforge.net/p/tei/feature-requests/457/ FR 457] : KH: In the ticket I want to clarify what you use tagUsage for and what to put in a project-specifi...
|KH, LB, JC
|KH, LB, and JC will review and make a recommendation to Council before the next face-to-face.
|KH emailed the others on 2013-12-26.
|-
|[https://sourceforge.net/p/tei/feature-requests/476/ FR 476] use of stage inside poetry, and using placement attribute (AMBER open). (Council agreed to @place; s...
|JC
|JC to close ticket FR 476 noting it has been resolved.
|[awaiting confirmation it has been documented.
|-
|[https://docs.google.com/document/d/1766WTJV2xcfANh8HRZW5m520yrC1nCzQJzUgKpwiylI/edit TEI Roma Replacement Specification] JC: The existing Roma is dated and flawed, as we all know. Many tickets have come up which we cannot...
|JC
|ALL Council to go through the proposal again and discuss it, remembering to look at the comments, and further refine it. JC to make sure it’s tidied up. Deadline: next teleconference.
|Not finished.
|-
|[https://sourceforge.net/p/tei/feature-requests/303/ FR 303] check the apache logs for frequent 404s (AMBER open). Action: JC to ask DS to make the TEI-C webserv...
|JC, MH
|JC to ask DS to make the TEI-C webserver logs available somewhere we can see them; then action on MH to write script to generate lists of bad links of various types. JC also to check google analytics/Webmaster tools. Deadline to report back by next conference call.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/305/ FR 305] Updating info on projects page (AMBER open). Project pages go out of date. There is a way to submit ...
|JC
|JC to ask DS to make that correction info available on each project page, along with its last-updated date if possible (and the latter should also show up on the bullet-point list).
|
|-
|[https://sourceforge.net/p/tei/feature-requests/466/ FR 466] Make it possible to add SIG labels to tickets (AMBER open). Action: JC as SIG Coordinator to tell th...
|JC
|JC as SIG Coordinator to tell the SIGs that if they wish, we can make their SIG convener a developer on SF and make it possible to assign SIG labels to tickets. Deadline: next teleconference.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/366/ FR 366] rationalize content models of org and place (etc) (AMBER open). Group thinks a small group of people...
|JC, LB, SB
|JC to make ticket red, should stay with JC, and he should initiate the process, working with LB and SB.
|
|-
|Ideas on how to run an experimental TEI Hackathon [SR]

|JC, HC, SR, EM
|JC to approach the DH 2014 committee and find out how they would prefer us to do it, and whether it’s a good idea; and tell the Board that HC, SR and EM are prepared to be involved in organizing this along with one or more Board members.
|Done
|-
|[https://sourceforge.net/p/tei/feature-requests/264/ FR 264] altIdentifier in msPart (AMBER pending-accepted). Action: JC to change to Green and assign to himsel...
|JC
|JC to change to Green and assign to himself, then nudge Torsten for an example of an altIdentifier within an msPart.
|Done (awaiting example)
|-
|[https://sourceforge.net/p/tei/bugs/276/ BUG 276] internationalisation links (AMBER open). Language links at bottom of a page should take you to same ...
|JC, SB
|JC to make Green and allocate to SB.
|Ticket Implemented by SR; Closed.
|-
|[https://sourceforge.net/p/tei/bugs/515/ BUG 515] Bad example of feature/@fVal (AMBER open). [Change this to RED as it’s not clear what needs changin...
|JC
|JC to check that’s been changed to RED [DONE].
|Done
|-
|[https://sourceforge.net/p/tei/bugs/582/ BUG 582] Need for consistency in terminology relating to TEI conformance (AMBER open). Working group: Agreed ...
|JC
|JC will create a ticket to reconsider the discussion of “conformable” and “conformant” in the Guidelines.
|
|-
|[https://sourceforge.net/p/tei/bugs/601/ BUG 601] att.patternReplacement/@matchPattern should be XPath regex, not XML Schema (AMBER open). Action: JC ...
|JC
|JC to close as a dupe of FR 432.
|Done
|-
|[https://sourceforge.net/p/tei/feature-requests/460/ FR 460] Use of geogFeat in transcription? (GREEN open). Ok. Action: JC to do it before next teleconference....
|JC
|JC to do it before next teleconference.
|not done
|-
|[https://sourceforge.net/p/tei/feature-requests/474/ FR 474] add an exemplum for @ref (GREEN open). Action: JC to poke JC; deadline by next teleconference....
|JC
|JC to poke JC; deadline by next teleconference.
|Done
|-
|[https://sourceforge.net/p/tei/feature-requests/475/ FR 475] Stop using attributes to store space-delimited values (GREEN open). Nothing wrong with space-delimit...
|JC
|JC to Close as Closed-rejected.
|Done
|-
|[https://sourceforge.net/p/tei/feature-requests/401/ FR 401] extend and clarify use of particDesc and settingDesc (GREEN open). JC admits sloth and will implemen...
|JC
|JC to implement before next teleconference; Council decides it might be better to add these (model.
|Done
|-
|[http://sourceforge.net/p/tei/feature-requests/378/ FR 378] ; c.f. A Generic Formalism for Encoding Standoff annotations in TEI). Action: JC to ask Peter Stadle...
|JC, HC, SB
|JC to ask Peter Stadler if he’d like to attend as Council rep; otherwise any interested members of Council (HC,SB) are encouraged to attend virtually.
|Done
|-
|[https://sourceforge.net/p/tei/bugs/229/ BUG 229] Check desc of all xs:anyURI atts for in-doc restrictions (GREEN pending). We got rid of data.code al...
|JC
|JC to check prose discussion all xsd:anyURI attributes by next teleconference.
|pending
|-
|[https://sourceforge.net/p/tei/bugs/336/ BUG 336] AdBlock blocks 'msad' ID (GREEN pending-later). Per last comment, time has passed and nothing else h...
|JC
|JC to close ticket.
|Done
|-
|[https://sourceforge.net/p/tei/bugs/587/ BUG 587] Guidelines version info on pages should link better (GREEN open). Action: JC to carry out his last c...
|JC
|JC to carry out his last comment on the ticket.
|not done
|-
|[https://sourceforge.net/p/tei/bugs/519/ BUG 519] Make lb, pb, cb, gb consistent (GREEN open-accepted). Council decided to close. Action: JC to close ...
|JC
|JC to close [DONE].
|Done
|-
|[https://sourceforge.net/p/tei/bugs/525/ BUG 525] citedRange and biblScope should share att class (GREEN open). SB admitted to sloth. Action: SB to co...
|MH, JC, KH
|MH to check Allura settings to make sure that the owners of both bugs and feature requests receive email notifications. [JC and KH looked into this during a break and might have fixed it through another mechanism. MH to check with JC].
|unsure
|-
|[https://sourceforge.net/p/tei/bugs/418/ BUG 418] Names and Dates chapter does not mention calendar (GREEN open). Action: JC will add the prose before...
|JC
|JC will add the prose before the next teleconference.
|not done
|}

===Actions for Kevin Hawkins===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|[https://sourceforge.net/p/tei/feature-requests/457/ FR 457] : KH: In the ticket I want to clarify what you use tagUsage for and what to put in a project-specifi...
|KH, LB, JC
|KH, LB, and JC will review and make a recommendation to Council before the next face-to-face.
|Discussion happening on ticket.
|-
|[https://sourceforge.net/p/tei/feature-requests/384/ FR 384] that once 384 is implemented, we’ll add a note on att.typed reminding people that this is meant for ...
|HC, KH
|HC will implement [DONE]. KH will add a comment to FR 384 [DONE].
|done during Council meeting
|-
|[https://sourceforge.net/p/tei/feature-requests/468/ FR 468] : HC: precision expresses false precision that’s not real probability. It’s something more like cert...
|KH
|KH to add to the deprecation document the requirement to announce to the community that we plan to deprecate something and to get in touch if you object.
|done 2013-12-26
|-
|[https://sourceforge.net/p/tei/feature-requests/383/ FR 383] where to put idno within biblStruct? (AMBER open) This is one of three tickets where KH could not fi...
|KH, SB
|KH will create a new ticket pointing to this and the other two tickets with deprecation problems (as listed on the wiki) saying we need a way to deprecate members of content model and reassign to SB to solve the three tickets using a Schematron warning, and to add @validUntil on constraintSpec.
|done 2013-12-08 (new ticket is at https://sourceforge.net/p/tei/feature-requests/486/)
|-
|[https://sourceforge.net/p/tei/feature-requests/482/ FR 482] The term strikes back - terminology chapter (AMBER open). The ISO is working on a standard for termi...
|LB, KH, SB
|LB, KH and SB to articulate a more generic policy for TEI on the integration of external standards and will generate a one-page proposal for this policy. This should be provided to Council ahead of the next teleconference. In addition, LB, KH, and SB will check with Laurent that he wants TBX incorporated into the Guidelines as is or kept in sync in the future and what he thinks about melding into the rest of the TEI Guidelines (in language, approach, element naming conventions) or keeping it self-contained.
|Kevin drafted a [http://www.tei-c.org/Activities/Council/Working/tcw28.xml generic policy] and circulated to Lou and Syd on 2013-12-26. Discussion of whether to incorporate TBX into the Guidelines is [http://sourceforge.net/p/tei/feature-requests/482/#28f3 happening on ticket].
|-
|[https://sourceforge.net/p/tei/feature-requests/294/ FR 294] altIdentifier is deprecated within msPart (AMBER open). Action: KH to change to Green and add to the...
|KH
|KH to change to Green and add to the ticket about deprecation using Schematron along with 383, if not already done.
|done 2013-12-08
|-
|[https://sourceforge.net/p/tei/bugs/528/ BUG 528] consistency in "the Guidelines" vs. "these Guidelines" (AMBER open). This should be green. Action: K...
|KH
|KH to do this.
|
|-
|[https://sourceforge.net/p/tei/bugs/548/ BUG 548] use of modal verbs in Guidelines (AMBER pending-later). Already assigned to KH. RW agreed to help. I...
|KH, RW, LB
|KH and RW to create a new, detailed ticket with all questionable cases. In the meantime, LB will fix the edits that KH made at r12525.
|LB commented out otiose paragraph.
|-
|[https://sourceforge.net/p/tei/bugs/216/ BUG 216] half title pages in TEI Tite (AMBER open-postponed). KH has to finish comparing TEI-Tite with the Ap...
|KH
|KH to resolve Tite problems and report regularly to Council on progress.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/280/ FR 280] clarification of colloc (GREEN pending-accepted). #1 is already done. #2: Breakout group agreed that...
|KH
|KH to remove @type from both examples, etc.
|done 2013-12-26
|-
|[https://sourceforge.net/p/tei/feature-requests/482/ FR 482] Earlier we decided:Action: LB, KH and SB to articulate a more generic policy for TEI on the integrat...
|LB, KH, SB
|LB, KH and SB to articulate a more generic policy for TEI on the integration of external standards and will generate a one-page proposal for this policy. This should be provided to Council ahead of the next teleconference. In addition, LB, KH, and SB will check with Laurent that he wants TBX incorporated into the Guidelines as is or kept in sync in the future and what he thinks about melding into the rest of the TEI Guidelines (in language, approach, element naming conventions) or keeping it self-contained.
|Kevin drafted a [http://www.tei-c.org/Activities/Council/Working/tcw28.xml generic policy] and circulated to Lou and Syd on 2013-12-26. Discussion of whether to incorporate TBX into the Guidelines is [http://sourceforge.net/p/tei/feature-requests/482/#28f3 happening on ticket].
|-
|[https://sourceforge.net/p/tei/bugs/525/ BUG 525] citedRange and biblScope should share att class (GREEN open). SB admitted to sloth. Action: SB to co...
|MH, JC, KH
|MH to check Allura settings to make sure that the owners of both bugs and feature requests receive email notifications. [JC and KH looked into this during a break and might have fixed it through another mechanism. MH to check with JC].
|n/a
|}

===Actions for Martin Holmes===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|[https://sourceforge.net/p/tei/feature-requests/453/ FR 453] a place for metadata that you can't fit into existing header elements AMBER open Discussion talks mo...
|MH, PS, LB
|MH will offer DC examples and PS will offer MARC examples. LB will pull them together into some text to be inserted into the Guidelines. Given this, Council will reconsider the feature request and whether to create the wrapper element.
|Examples provided 2013-11-20
|-
|[https://sourceforge.net/p/tei/feature-requests/471/ FR 471] extend the possible usages of argument (AMBER open). (If the intended use case is encoder-supplied a...
|LB, MH
|
|Done. Fourth example added in rev 12666 2013-11-27.
|-
|[https://sourceforge.net/p/tei/feature-requests/472/ FR 472] docDate in dateline ? EM: dateline does not allow docDate, but byline allows docAuthor. This is inco...
|MH
|MH to add docDate to dateline, and clarify with usage notes.
|Done 2013-11
|-
|[https://sourceforge.net/p/tei/feature-requests/443/ FR 443] @resp should be a member of att.global AMBER open. JC and SR: Global attributes should really not be...
|MH, LB
|MH and LB to agree on clarification to Guidelines to say that @resp means different things: responsibility for markup and content except when the element in question is a transcriptional element, in which case the content of the element is marked as coming from the source.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/303/ FR 303] check the apache logs for frequent 404s (AMBER open). Action: JC to ask DS to make the TEI-C webserv...
|JC, MH
|JC to ask DS to make the TEI-C webserver logs available somewhere we can see them; then action on MH to write script to generate lists of bad links of various types. JC also to check google analytics/Webmaster tools. Deadline to report back by next conference call.
|I've checked through the logs, which the webmaster provided for me. There seem to be no instances of systematic errors. There seems to be little to gain from this, assuming the sysadmins are already routine monitoring.
|-
|[https://sourceforge.net/p/tei/feature-requests/470/ FR 470] att.measurement and att.dimensions overlap (AMBER open). We are not really sure why all of these att...
|MH
|MH to move @commodity into its own class, and move measure and measureGrp to att.dimensions. Ticket to GREEN, assign to MH. [Subsequent study suggests to MH that this may be more complicated than it seems, and may have to wait on our having the ability to override valLists in attributes from attribute classes at the element level.]
|Set back to Amber pending further discussion. See ticket for details.
|-
|[http://wiki.tei-c.org/index.php/Council_agenda_2013-11#More_Details_on_Agenda_topics bottom of wiki agenda page] ) SR: Why are we proposing using alpha and beta? MH: Because we were proposing asking the community ...
|MH, SR
|Assign MH to update the release documentation re alpha and beta, and investigate how we might add the SVN last changed date and the rev number to the bottom of pages.
|Latter bit done by SR 2013-11-14. Documentation in TCW22 updated by MH 2013-11-14.
|-
|[https://sourceforge.net/p/tei/feature-requests/405/ FR 405] Wrong schema generated (AMBER pending-accepted). This is due to a bug in the current version in Roma...
|MH
|MH to see if it has been fixed, and if so, close the ticket.
|Done 2013-11
|-
|[https://sourceforge.net/p/tei/feature-requests/342/ FR 342] [http://wiki.tei-c.org/index.php/Text_Directionality_Draft first draft of new Guidelines sections] and questions [MH] MH summarized the genesis of this text from Providence.
|MH, LB
|Entire Council to (re)read MH’s draft before next face-to-face meeting. Once we’ve done that and agreed, someone will rewrite chapter 5 (WD) to include MH’s draft and the current section 10.6.6. LB volunteered.
|Council and the WG members have been asked to read and comment on the draft (2013-11-28).
|-
|[https://sourceforge.net/p/tei/bugs/578/ BUG 578] partial and recursive segmentation of s-units (AMBER open). [The Guidelines text is clear enough. Th...
|MH
|MH will revise content model to match the prose.
|Done 2013-11-27, although I really don't like the results of this.
|-
|[https://sourceforge.net/p/tei/feature-requests/298/ BUG 298] att.editLike should not bring att.dimensions & att.ranging (AMBER open-accepted). [MH to ask Gabriel...
|MH
|MH to ask Gabby to implement.
|GB has asked to pass the ticket to MH (2013-11-28). MH to create a full proposal and implement if approved.
|-
|[https://sourceforge.net/p/tei/feature-requests/212/ FR 212] Generic dating class (AMBER pending-accepted). Gabby claimed in 2011 that it’s done except needs som...
|HC, MH
|HC to investigate whether it’s actually been done. MH offered examples if needed.
|
|-
|[https://sourceforge.net/p/tei/bugs/568/ BUG 568] "How to edit the Guidelines" and chapter organization (AMBER open). SR: What MH found looks distinct...
|MH
|MH to replace references to entity references with explanation of XIncludes in “How to edit the Guidelines”.
|Done 2013-11
|-
|[https://sourceforge.net/p/tei/bugs/506/ BUG 506] Meaning of @corresp rather in dispute (AMBER open). Working group triage: needs to be discussed: Is ...
|MH
|MH to create an example and run it by tei-council before adding to the Guidelines.
|Done 2013-12-23
|-
|[https://sourceforge.net/p/tei/bugs/582/ BUG 582] Need for consistency in terminology relating to TEI conformance (AMBER open). Working group: Agreed ...
|MH
|MH to deal with the ticket narrowly, using a hyphen and lowercase but leaving both “conformant” and “conformable”.
|Done 2013-11-20
|-
|[https://sourceforge.net/p/tei/bugs/460/ BUG 460] list/@type="unordered" is not recommended, but used often (AMBER open). Working group: This bug has...
|MH
|MH to follow the last comment on ticket to figure out our current situation.
|Research done, and a proposal being developed [http://wiki.tei-c.org/index.php/List_types_and_rendering on the wiki].
|-
|[https://sourceforge.net/p/tei/bugs/581/ BUG 581] `attRef` needs better documentation (AMBER open). Action: SR to implement either removal of attRef, ...
|SR, MH
|SR to implement either removal of attRef, MH to adjust documentation.
|SR recommends holding off on documentation because he may be able to eliminate attRef in favour of classRef.
|-
|[https://sourceforge.net/p/tei/feature-requests/432/ FR 432] Change regex flavor on @matchPattern (GREEN open). Agreed, XPath. Action: MH Write to TEI-L list, if...
|MH
|MH Write to TEI-L list, if no negative feedback, change.
|Done 2013-11-21 rev 12660
|-
|[https://sourceforge.net/p/tei/bugs/312/ BUG 312] i18n revision due (GREEN open). Action: MH, when he completes action on related ticket (perhaps afte...
|MH
|MH, when he completes action on related ticket (perhaps after moving notes from minutes into tickets), to update this ticket.
|Some contacts made with potential translators 2013-12; suggestion for a pilot project with Italian and Chinese posted to Council list.
|-
|[https://sourceforge.net/p/tei/bugs/442/ BUG 442] update ODD documentation on www.tei-c.org and in Guidelines (GREEN open). Action: MH to finish it....
|MH
|MH to finish it.
|
|-
|[https://sourceforge.net/p/tei/bugs/441/ BUG 441] fDecl doesn't allow att.datcat yet (GREEN open-accepted). Action: MH to prod Piotr....
|MH
|MH to prod Piotr.
|Piotr prodded 2013-11-21, and twice more after that.
|-
|[https://sourceforge.net/p/tei/bugs/525/ BUG 525] citedRange and biblScope should share att class (GREEN open). SB admitted to sloth. Action: SB to co...
|MH, JC, KH
|MH to check Allura settings to make sure that the owners of both bugs and feature requests receive email notifications. [JC and KH looked into this during a break and might have fixed it through another mechanism. MH to check with JC].
|According to investigation, we've done what we can with Allura settings here.
|}

===Actions for Elli Mylonas===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|Ideas on how to run an experimental TEI Hackathon [SR]

|JC, HC, SR, EM
|JC to approach the DH 2014 committee and find out how they would prefer us to do it, and whether it’s a good idea; and tell the Board that HC, SR and EM are prepared to be involved in organizing this along with one or more Board members.
|
|-
|Ideas on how to run an experimental TEI Hackathon [SR]

|EM
|EM to make sure this happens.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/300/ FR 300] Move witStart et al. to model.milestoneLike (AMBER pending). Action: EM to change to red and assigne...
|EM
|EM to change to red and assigned to EM to chase up or otherwise close ticket.
|
|-
|[https://sourceforge.net/p/tei/bugs/594/ BUG 594] TEI-C website menu points to wrong index page for Guidelines (AMBER open). Fixed, will appear in nex...
|EM
|EM to create a ticket on the Chrome problem.
|
|-
|[https://sourceforge.net/p/tei/bugs/589/ BUG 589] add respons and space to att.responsibility (AMBER open). Working group triage: Is it ok to add have...
|EM
|EM will get rid of locally assigned @resp by adding to att.responsibility (thereby getting @cert as well). Will change to GREEN.
|
|-
|[https://sourceforge.net/p/tei/bugs/563/ BUG 563] inconsistent encoding of citations to sources of examples (AMBER open). Working group recommends ass...
|BB, EM, PS
|BB, EM, and PS to work on the ticket by mid-February 2014.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/389/ FR 389] clarify definition of @from on locus and biblScope (GREEN open). EM admits to sloth and will do so. ...
|EM
|EM to do before next teleconference.
|
|-
|[http://wiki.tei-c.org/index.php/TEI_Cheatsheets Cheatsheets: Short best/recommended practice documents] EM: Not cheatsheets - negative implication. RW: Quick Start. HC: Quick Reference; SB: “Guidelettes” ...
|EM
|EM to ask MB to clarify what she wants from Council with regard to helping cheatsheets.
|
|}

===Actions for Sebastian Rahtz===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|[http://tei.oucs.ox.ac.uk/EEBO/ http://tei.oucs.ox.ac.uk/EEBO/] for summary of problem, and links to tickets) SR: EEBO-TCP is a gigantic resource that claims to be ...
|SR
|SR will implement the schema change of adding @place to stage and will document and provide an example.
|adding @place. example to do
|-
|[https://sourceforge.net/p/tei/feature-requests/479/ FR 479] Adding the @place attribute to head and seg AMBER open JC noted that head is not meta-textual or in ...
|SR
|SR to take the ticket, and get more examples from the submitter
|DONE
|-
|[https://sourceforge.net/p/tei/feature-requests/445/ FR 445] Conversion of ODD to HTML: Examples should be aware of element renaming closed-fixed, implemented by...
|SR
|SR to add gi and att renaming to complete the ticket.
| COMPLETED FOR gi. Not possible for att.
|-
|[https://sourceforge.net/p/tei/feature-requests/442/ FR 442] Allow foreign to contain q (AMBER open). The group felt this should be rejected. Action:SR to close ...
|SR
|SR to close ticket because it’s rejected
|DONE
|-
|[https://sourceforge.net/p/tei/feature-requests/433/ FR 433] loosen content model of salute (AMBER open). SR: Underlying this was a desire for symmetry between s...
|SR
|SR will carry this out
|DONE
|-
|[https://sourceforge.net/p/tei/feature-requests/477/ FR 477] lines of poetry inside trailer (AMBER open). The request is for symmetry between head and trailer. T...
|SR
|SR to find a good way to achieve this, since what was done before with head was rather strange.
|DONE. Have copied what was done with head
|-
|[https://sourceforge.net/p/tei/feature-requests/383/ FR 383] where to put idno within biblStruct? (AMBER open) This is one of three tickets where KH could not fi...
|SR
|SR to check how @validUntil makes the build fail when out of date, and if necessary update this mechanism so it can handle @validUntil on constraintSpec. Ticket 383 will wait on all this, along with the two other tickets.
|DONE. It applies to tei:*[@validUntil], so should just work.] .
|-
|[http://wiki.tei-c.org/index.php/Council_agenda_2013-11#More_Details_on_Agenda_topics bottom of wiki agenda page] ) SR: Why are we proposing using alpha and beta? MH: Because we were proposing asking the community ...
|MH, SR
|Assign MH to update the release documentation re alpha and beta, and investigate how we might add the SVN last changed date and the rev number to the bottom of pages.
|Latter bit done by SR 2013-11-14. Documentation in TCW22 updated by MH 2013-11-14.]
|-
|Ideas on how to run an experimental TEI Hackathon [SR]
|JC, HC, SR, EM
|JC to approach the DH 2014 committee and find out how they would prefer us to do it, and whether it’s a good idea; and tell the Board that HC, SR and EM are prepared to be involved in organizing this along with one or more Board members.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/345/ FR 345] members of model.respLike should be members of att.declarable (AMBER open-later). Breakout group ins...
|SR
|SR to make the ticket Green and go ahead and implement it, including some documentation/examples.
|DONE
|-
|[https://sourceforge.net/p/tei/bugs/302/ BUG 302] version ignores @source (AMBER open). This is a Roma issue. Recommend marking as closed won’t fix be...
|SR
|SR to try reproducing this and set as closed-won’t fix.
|DONE
|-
|[https://sourceforge.net/p/tei/bugs/583/ BUG 583] Adding new attribute fails in Roma schema generation (AMBER open). Same as 302. Action: SR wil set a...
|SR
|SR wil set as closed-won’t fix and check that it has the Roma tag.
|DONE
|-
|[https://sourceforge.net/p/tei/bugs/434/ BUG 434] issues with ePub conversion (2/3) (AMBER open). Any issue not dealing with ODD processing should be ...
|SR
|SR will ask poster kindly to post there (explaining why) and close this issue.
|DONE
|-
|[https://sourceforge.net/p/tei/bugs/581/ BUG 581] `attRef` needs better documentation (AMBER open). Action: SR to implement either removal of attRef, ...
|SR, MH
|SR to implement either removal of attRef, MH to adjust documentation.
|FIxed attRef. thinking about classRef
|-
|[https://sourceforge.net/p/tei/feature-requests/467/ FR 467] Make @name optional on tei:relation (GREEN open). Action: SR has already done this....
|SR
|SR to action
|DOne
|-
|[https://sourceforge.net/p/tei/feature-requests/478/ FR 478] loosening content and model of `signed` (GREEN open). Agree that is is green. Though would model.div...
|SR
|SR to implement signed at top as well as bottom
|DONE
|}

===Actions for Paul Schaffner===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|[https://sourceforge.net/p/tei/feature-requests/453/ FR 453] a place for metadata that you can't fit into existing header elements AMBER open Discussion talks mo...
|MH, PS, LB
|MH will offer DC examples and PS will offer MARC examples. LB will pull them together into some text to be inserted into the Guidelines. Given this, Council will reconsider the feature request and whether to create the wrapper element.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/360/ FR 360] New attribute @keepHyphen. Ticket open, ticket GREEN, it’s rejected throughout the comments....
|PS
|PS to provide an example of the mechanism recommended to handle the use-case.
|
|-
|[https://sourceforge.net/p/tei/bugs/563/ BUG 563] inconsistent encoding of citations to sources of examples (AMBER open). Working group recommends ass...
|BB, EM, PS
|BB, EM, and PS to work on the ticket by mid-February 2014.
|
|-
|[https://sourceforge.net/p/tei/bugs/558/ BUG 558] name/orgName (AMBER open). Action: RW to ask PS where he is on this; change ticket status to GREEN....
|RW, PS
|RW to ask PS where he is on this; change ticket status to GREEN.
|
|}

===Actions for Torsten Schassan===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|

|TS
|TS to come up with a more detailed problem description and what the WG should attempt to solve by 2014-01-01.
|
|}

===Actions for Rebecca Welzenbach===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|[https://sourceforge.net/p/tei/feature-requests/384/ FR 384] : In April RW made a spreadsheet showing which elements she recommends moving into att.typed. And in...
|SB, RW
|SB and RW will review the list again.
|
|-
|Attributes without examples

|BB, RW
|BB and RW to turn into bug reports those attributes that are without examples that are high priority or need new/updated definitions.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/377/ FR 377] retaining punctuation marks in the text of a TEI document (AMBER open-accepted). RW says she has add...
|RW
|RW to finish the work and ask for help if necessary.
|
|-
|[https://sourceforge.net/p/tei/bugs/548/ BUG 548] use of modal verbs in Guidelines (AMBER pending-later). Already assigned to KH. RW agreed to help. I...
|KH, RW, LB
|KH and RW to create a new, detailed ticket with all questionable cases. In the meantime, LB will fix the edits that KH made at r12525.
|
|-
|[https://sourceforge.net/p/tei/bugs/558/ BUG 558] name/orgName (AMBER open). Action: RW to ask PS where he is on this; change ticket status to GREEN....
|RW, PS
|RW to ask PS where he is on this; change ticket status to GREEN.
|
|-
|[https://sourceforge.net/p/tei/bugs/401/ BUG 401] Most attributes lack good examples (GREEN open-accepted). This was previously discussed. Action: RW ...
|RW
|RW to follow up.
|
|}

[[Category:Council]]

Oxford2013-Actions2

2014-01-10T12:23:24Z

Hcayless: /* Actions for Hugh Cayless */

==Council Actions from November 2013 Oxford Meeting==

A list of actions, those responsible, and what has been done about them from [http://www.tei-c.org/Activities/Council/Meetings/tcm56.xml Oxford 2013 face to face meeting] of TEI Technical Council

===Actions for Brett Barney===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|Attributes without examples

|BB, RW
|BB and RW to turn into bug reports those attributes that are without examples that are high priority or need new/updated definitions.
|
|-
|[https://sourceforge.net/p/tei/bugs/563/ BUG 563] inconsistent encoding of citations to sources of examples (AMBER open). Working group recommends ass...
|BB, EM, PS
|BB, EM, and PS to work on the ticket by mid-February 2014.
|
|-
|[https://sourceforge.net/p/tei/bugs/610/ BUG 610] "lem" used in a confusing way in CriticalApparatus.xml (AMBER open). Action: BB to remove the last c...
|BB
|BB to remove the last clause of the sentence in question, beginning ", or to make clear".
|Done 2013-11-13
|-
|[https://sourceforge.net/p/tei/bugs/387/ BUG 387] clarifying heading or title of a graphic (GREEN open). LB recently posted a comment approving of the...
|BB
|BB will implement the ticket.
|Done 2013-11-13
|}

===Actions for Lou Burnard===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|[https://sourceforge.net/p/tei/feature-requests/457/ FR 457] : KH: In the ticket I want to clarify what you use tagUsage for and what to put in a project-specifi...
|KH, LB, JC
|KH, LB, and JC will review and make a recommendation to Council before the next face-to-face.
|KH emailed the others on 2013-12-26; LB updated ticket and emailed the others 2014-01-05
|-
|[https://sourceforge.net/p/tei/feature-requests/453/ FR 453] a place for metadata that you can't fit into existing header elements AMBER open Discussion talks mo...
|MH, PS, LB
|MH will offer DC examples and PS will offer MARC examples. LB will pull them together into some text to be inserted into the Guidelines. Given this, Council will reconsider the feature request and whether to create the wrapper element.
|Added comment on ticket suggesting that the proposal seems doomed to be rejected; action to explain how to handle this situation in the Guidelines remains open.
|-
|[https://sourceforge.net/p/tei/feature-requests/471/ FR 471] extend the possible usages of argument (AMBER open). (If the intended use case is encoder-supplied a...
|LB, MH
|New element <abstract> added; examples added .
|Done 2013-11-12
|-
|Pure ODD

|LB
|LB to add the new elements and the documentation ahead of the next release; documentation need only be at the element level, along with some brief introduction in the Guidelines, to be expanded to a full section later.
|First pass completed 2013-12-01
|-
|[https://sourceforge.net/p/tei/feature-requests/443/ FR 443] @resp should be a member of att.global AMBER open. JC and SR: Global attributes should really not be...
|MH, LB
|MH and LB to agree on clarification to Guidelines to say that @resp means different things: responsibility for markup and content except when the element in question is a transcriptional element, in which case the content of the element is marked as coming from the source.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/366/ FR 366] rationalize content models of org and place (etc) (AMBER open). Group thinks a small group of people...
|JC, LB, SB
|JC to make ticket red, should stay with JC, and he should initiate the process, working with LB and SB.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/458/ FR 458] Make listBibl and model.biblLike member of model.personPart (AMBER open). Lou has already done items...
|LB
|close the ticket.
|Done
|-
|i18n: take forward updating translations

|LB
|LB to testdrive the spreadsheet.
|Done
|-
|[https://sourceforge.net/p/tei/feature-requests/482/ FR 482] The term strikes back - terminology chapter (AMBER open). The ISO is working on a standard for termi...
|LB, KH, SB
|LB, KH and SB to articulate a more generic policy for TEI on the integration of external standards and will generate a one-page proposal for this policy. This should be provided to Council ahead of the next teleconference. In addition, LB, KH, and SB will check with Laurent that he wants TBX incorporated into the Guidelines as is or kept in sync in the future and what he thinks about melding into the rest of the TEI Guidelines (in language, approach, element naming conventions) or keeping it self-contained.
|Kevin drafted a [http://www.tei-c.org/Activities/Council/Working/tcw28.xml generic policy] and circulated to Lou and Syd on 2013-12-26. Discussion of whether to incorporate TBX into the Guidelines is [http://sourceforge.net/p/tei/feature-requests/482/#28f3 happening on ticket].
|-
|[https://sourceforge.net/p/tei/feature-requests/480/ FR 480] Adding the @hand attribute to all (or most) text-containing elements (AMBER open). Breakout group wa...
|LB
|LB to respond to the ticket FR 480.
|
|-
|[http://wiki.tei-c.org/index.php/Text_Directionality_Draft first draft of new Guidelines sections] and questions [MH] MH summarized the genesis of this text from Providence. He noted that not only th...
|MH, LB
|Entire Council to (re)read MH’s draft before next face-to-face meeting. Once we’ve done that and agreed, someone will rewrite chapter 5 (WD) to include MH’s draft and the current section 10.6.6. LB volunteered.
|
|-
|[https://sourceforge.net/p/tei/bugs/548/ BUG 548] use of modal verbs in Guidelines (AMBER pending-later). Already assigned to KH. RW agreed to help. I...
|KH, RW, LB
|KH and RW to create a new, detailed ticket with all questionable cases. In the meantime, LB will fix the edits that KH made at r12525.
|Commented out otiose paragraph.
|-
|[https://sourceforge.net/p/tei/bugs/468/ BUG 468] Order of elements in publicationStmt (AMBER open-accepted). Group discussion: SB: Despite Lou’s comm...
|SB, LB
|SB will do the content model and LB will do the prose. They’ll work out the specifics.
|Emailed syd 2014-01-05
|-
|[https://sourceforge.net/p/tei/feature-requests/469/ FR 469] add extent to att.dimensions (GREEN open). Agreed. Action: LB to provide an example in HD chapter (2...
|LB
|LB to provide an example in HD chapter (2.2.3) and close ticket.
|Done 2013-11-20
|-
|[https://sourceforge.net/p/tei/bugs/605/ BUG 605] clarifying add vs. supplied and del vs. surplus (AMBER open). Action: HC to emend the prose of the p...
|HC, LB
|HC to emend the prose of the paragraph beginning "The add element should not be used" to reference the surplus element also; LB points out that the specList can't be modified, because supplied/surplus aren't defined in Core.
|Done, I think.
|-
|[https://sourceforge.net/p/tei/bugs/609/ BUG 609] "lemma" used in a confusing way in CriticalApparatus.xml (AMBER open). Action: LB to remove the phra...
|LB
|LB to remove the phrase "on any one lemma" from the @varSeq description.
|Done, 2013-11-13
|-
|[https://sourceforge.net/p/tei/feature-requests/461/ FR 461] Two small improvements to `recording` (GREEN open). Action: LB to do this by next teleconference....
|LB
|LB to do this by next teleconference.
|Done 2013-11-13
|-
|[https://sourceforge.net/p/tei/feature-requests/482/ FR 482] Earlier we decided:Action: LB, KH and SB to articulate a more generic policy for TEI on the integrat...
|LB, KH, SB
|LB, KH and SB to articulate a more generic policy for TEI on the integration of external standards and will generate a one-page proposal for this policy. This should be provided to Council ahead of the next teleconference. In addition, LB, KH, and SB will check with Laurent that he wants TBX incorporated into the Guidelines as is or kept in sync in the future and what he thinks about melding into the rest of the TEI Guidelines (in language, approach, element naming conventions) or keeping it self-contained.
|Kevin drafted a [http://www.tei-c.org/Activities/Council/Working/tcw28.xml generic policy] and circulated to Lou and Syd on 2013-12-26. Discussion of whether to incorporate TBX into the Guidelines is [http://sourceforge.net/p/tei/feature-requests/482/#28f3 happening on ticket].
|-
|Correspondence SIG:

|SB, LB
|SB and LB would like to (re?-)join the task force. Council advises them to keep in mind the work by the Ontology/MS SIGs, in particular Torsten Schassan, on an ‘object’ or ‘objectDesc’ element.
|
|}

===Actions for Syd Bauman===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|[https://sourceforge.net/p/tei/feature-requests/384/ FR 384] : In April RW made a spreadsheet showing which elements she recommends moving into att.typed. And in...
|SB, RW
|SB and RW will review the list again.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/459/ FR 459] : This is just waiting for implementation....
|SB
|SB will implement by end of January 2014.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/481/ FR 481] check that all sibling att.translatable elements have @versionDate (AMBER open). (Agreed that siblin...
|SB
|SB to check whether this is implemented, and if not, get it implemented then close the ticket.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/468/ FR 468] : HC: precision expresses false precision that’s not real probability. It’s something more like cert...
|SB
|
|
|-
|[https://sourceforge.net/p/tei/feature-requests/383/ FR 383] where to put idno within biblStruct? (AMBER open) This is one of three tickets where KH could not fi...
|KH, SB
|KH will create a new ticket pointing to this and the other two tickets with deprecation problems (as listed on the wiki) saying we need a way to deprecate members of content model and reassign to SB to solve the three tickets using a Schematron warning, and to add @validUntil on constraintSpec.
|This ticket reassigned to Syd, and new ticket created: https://sourceforge.net/p/tei/feature-requests/486/ .
|-
|[https://sourceforge.net/p/tei/feature-requests/366/ FR 366] rationalize content models of org and place (etc) (AMBER open). Group thinks a small group of people...
|JC, LB, SB
|JC to make ticket red, should stay with JC, and he should initiate the process, working with LB and SB.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/482/ FR 482] The term strikes back - terminology chapter (AMBER open). The ISO is working on a standard for termi...
|LB, KH, SB
|LB, KH and SB to articulate a more generic policy for TEI on the integration of external standards and will generate a one-page proposal for this policy. This should be provided to Council ahead of the next teleconference. In addition, LB, KH, and SB will check with Laurent that he wants TBX incorporated into the Guidelines as is or kept in sync in the future and what he thinks about melding into the rest of the TEI Guidelines (in language, approach, element naming conventions) or keeping it self-contained.
|Kevin drafted a [http://www.tei-c.org/Activities/Council/Working/tcw28.xml generic policy] and circulated to Lou and Syd on 2013-12-26. Discussion of whether to incorporate TBX into the Guidelines is [http://sourceforge.net/p/tei/feature-requests/482/#28f3 happening on ticket].
|-
|[https://sourceforge.net/p/tei/bugs/276/ BUG 276] internationalisation links (AMBER open). Language links at bottom of a page should take you to same ...
|JC, SB
|JC to make Green and allocate to SB.
|
|-
|[https://sourceforge.net/p/tei/bugs/619/ BUG 619] tei_allPlus.rng: conflicting ID-types for attribute "id" of element "partialdiff" from namespace "ht...
|SB
|SB to double-check whether able to reproduce and report back on ticket if able to.
|
|-
|[https://sourceforge.net/p/tei/bugs/288/ BUG 288] deprecate use of gram except as a child of gramGrp (AMBER open-accepted). [This is pending creation ...
|SB
|SB to create the new ticket and write the Schematron for this particular deprecation.
|Elsewhere we decided that KH would create the new ticket, which he's done at https://sourceforge.net/p/tei/feature-requests/486/ . But SB still needs to solve this ticket.
|-
|[https://sourceforge.net/p/tei/bugs/468/ BUG 468] Order of elements in publicationStmt (AMBER open-accepted). Group discussion: SB: Despite Lou’s comm...
|SB, LB
|SB will do the content model and LB will do the prose. They’ll work out the specifics.
|
|-
|[https://sourceforge.net/p/tei/bugs/405/ BUG 405] XPointer schemes may not nest, but see ch. 16 (AMBER open). Action: SB to fix documentation....
|SB
|SB to fix documentation.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/482/ FR 482] Earlier we decided:Action: LB, KH and SB to articulate a more generic policy for TEI on the integrat...
|LB, KH, SB
|LB, KH and SB to articulate a more generic policy for TEI on the integration of external standards and will generate a one-page proposal for this policy. This should be provided to Council ahead of the next teleconference. In addition, LB, KH, and SB will check with Laurent that he wants TBX incorporated into the Guidelines as is or kept in sync in the future and what he thinks about melding into the rest of the TEI Guidelines (in language, approach, element naming conventions) or keeping it self-contained.
|Kevin drafted a [http://www.tei-c.org/Activities/Council/Working/tcw28.xml generic policy] and circulated to Lou and Syd on 2013-12-26. Discussion of whether to incorporate TBX into the Guidelines is [http://sourceforge.net/p/tei/feature-requests/482/#28f3 happening on ticket].
|-
|[http://sourceforge.net/p/tei/feature-requests/378/ FR 378] ; c.f. A Generic Formalism for Encoding Standoff annotations in TEI). Action: JC to ask Peter Stadle...
|JC, HC, SB
|JC to ask Peter Stadler if he’d like to attend as Council rep; otherwise any interested members of Council (HC,SB) are encouraged to attend virtually.
|
|-
|Correspondence SIG:

|SB, LB
|SB and LB would like to (re?-)join the task force. Council advises them to keep in mind the work by the Ontology/MS SIGs, in particular Torsten Schassan, on an ‘object’ or ‘objectDesc’ element.
|
|-
|[https://sourceforge.net/p/tei/bugs/525/ BUG 525] citedRange and biblScope should share att class (GREEN open). SB admitted to sloth. Action: SB to co...
|SB
|SB to complete.
|
|}

===Actions for Hugh Cayless===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|Report on specification and estimated cost for XPointer resolver [HC/SB]

|HC
|HC to report on XPointer resolver and whether we should progress it.
|Draft GLs revision posted on [http://hcayless.github.io/TEI-Guidelines/Guidelines-web/en/html/SA.html#SATS GitHub]
|-
|[https://sourceforge.net/p/tei/feature-requests/465/ FR 465] : Gabby and HC seem to agree on it, and the example looks sensible. LB’s comment could be raised as ...
|HC
|HC will implement before end of January 2014.
|Done.
|-
|[https://sourceforge.net/p/tei/feature-requests/384/ FR 384] that once 384 is implemented, we’ll add a note on att.typed reminding people that this is meant for ...
|HC, KH
|HC will implement [DONE]. KH will add a comment to FR 384 [DONE].
|done during Council meeting
|-
|[https://sourceforge.net/p/tei/feature-requests/462/ FR 462] idno@type='uri' for Linked Data AMBER open (We agreed. @type=”URI” alongside @type=”URL”) EM: The su...
|HC
|HC to implement this and close the ticket FR 462.
|Done.
|-
|[https://sourceforge.net/p/tei/feature-requests/468/ FR 468] : HC: precision expresses false precision that’s not real probability. It’s something more like cert...
|HC
|HC to email TEI-L.
|FR implemented at meeting and email sent. No agitated (or indeed, any) responses.
|-
|Ideas on how to run an experimental TEI Hackathon [SR]

|JC, HC, SR, EM
|JC to approach the DH 2014 committee and find out how they would prefer us to do it, and whether it’s a good idea; and tell the Board that HC, SR and EM are prepared to be involved in organizing this along with one or more Board members.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/212/ FR 212] Generic dating class (AMBER pending-accepted). Gabby claimed in 2011 that it’s done except needs som...
|HC, MH
|HC to investigate whether it’s actually been done. MH offered examples if needed.
|
|-
|[https://sourceforge.net/p/tei/bugs/605/ BUG 605] clarifying add vs. supplied and del vs. surplus (AMBER open). Action: HC to emend the prose of the p...
|HC, LB
|HC to emend the prose of the paragraph beginning "The add element should not be used" to reference the surplus element also; LB points out that the specList can't be modified, because supplied/surplus aren't defined in Core.
|Done.
|-
|[http://sourceforge.net/p/tei/feature-requests/378/ FR 378] ; c.f. A Generic Formalism for Encoding Standoff annotations in TEI). Action: JC to ask Peter Stadle...
|JC, HC, SB
|JC to ask Peter Stadler if he’d like to attend as Council rep; otherwise any interested members of Council (HC,SB) are encouraged to attend virtually.
|
|}

===Actions for James Cummings===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|[https://sourceforge.net/p/tei/feature-requests/457/ FR 457] : KH: In the ticket I want to clarify what you use tagUsage for and what to put in a project-specifi...
|KH, LB, JC
|KH, LB, and JC will review and make a recommendation to Council before the next face-to-face.
|KH emailed the others on 2013-12-26.
|-
|[https://sourceforge.net/p/tei/feature-requests/476/ FR 476] use of stage inside poetry, and using placement attribute (AMBER open). (Council agreed to @place; s...
|JC
|JC to close ticket FR 476 noting it has been resolved.
|[awaiting confirmation it has been documented.
|-
|[https://docs.google.com/document/d/1766WTJV2xcfANh8HRZW5m520yrC1nCzQJzUgKpwiylI/edit TEI Roma Replacement Specification] JC: The existing Roma is dated and flawed, as we all know. Many tickets have come up which we cannot...
|JC
|ALL Council to go through the proposal again and discuss it, remembering to look at the comments, and further refine it. JC to make sure it’s tidied up. Deadline: next teleconference.
|Not finished.
|-
|[https://sourceforge.net/p/tei/feature-requests/303/ FR 303] check the apache logs for frequent 404s (AMBER open). Action: JC to ask DS to make the TEI-C webserv...
|JC, MH
|JC to ask DS to make the TEI-C webserver logs available somewhere we can see them; then action on MH to write script to generate lists of bad links of various types. JC also to check google analytics/Webmaster tools. Deadline to report back by next conference call.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/305/ FR 305] Updating info on projects page (AMBER open). Project pages go out of date. There is a way to submit ...
|JC
|JC to ask DS to make that correction info available on each project page, along with its last-updated date if possible (and the latter should also show up on the bullet-point list).
|
|-
|[https://sourceforge.net/p/tei/feature-requests/466/ FR 466] Make it possible to add SIG labels to tickets (AMBER open). Action: JC as SIG Coordinator to tell th...
|JC
|JC as SIG Coordinator to tell the SIGs that if they wish, we can make their SIG convener a developer on SF and make it possible to assign SIG labels to tickets. Deadline: next teleconference.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/366/ FR 366] rationalize content models of org and place (etc) (AMBER open). Group thinks a small group of people...
|JC, LB, SB
|JC to make ticket red, should stay with JC, and he should initiate the process, working with LB and SB.
|
|-
|Ideas on how to run an experimental TEI Hackathon [SR]

|JC, HC, SR, EM
|JC to approach the DH 2014 committee and find out how they would prefer us to do it, and whether it’s a good idea; and tell the Board that HC, SR and EM are prepared to be involved in organizing this along with one or more Board members.
|Done
|-
|[https://sourceforge.net/p/tei/feature-requests/264/ FR 264] altIdentifier in msPart (AMBER pending-accepted). Action: JC to change to Green and assign to himsel...
|JC
|JC to change to Green and assign to himself, then nudge Torsten for an example of an altIdentifier within an msPart.
|Done (awaiting example)
|-
|[https://sourceforge.net/p/tei/bugs/276/ BUG 276] internationalisation links (AMBER open). Language links at bottom of a page should take you to same ...
|JC, SB
|JC to make Green and allocate to SB.
|Ticket Implemented by SR; Closed.
|-
|[https://sourceforge.net/p/tei/bugs/515/ BUG 515] Bad example of feature/@fVal (AMBER open). [Change this to RED as it’s not clear what needs changin...
|JC
|JC to check that’s been changed to RED [DONE].
|Done
|-
|[https://sourceforge.net/p/tei/bugs/582/ BUG 582] Need for consistency in terminology relating to TEI conformance (AMBER open). Working group: Agreed ...
|JC
|JC will create a ticket to reconsider the discussion of “conformable” and “conformant” in the Guidelines.
|
|-
|[https://sourceforge.net/p/tei/bugs/601/ BUG 601] att.patternReplacement/@matchPattern should be XPath regex, not XML Schema (AMBER open). Action: JC ...
|JC
|JC to close as a dupe of FR 432.
|Done
|-
|[https://sourceforge.net/p/tei/feature-requests/460/ FR 460] Use of geogFeat in transcription? (GREEN open). Ok. Action: JC to do it before next teleconference....
|JC
|JC to do it before next teleconference.
|not done
|-
|[https://sourceforge.net/p/tei/feature-requests/474/ FR 474] add an exemplum for @ref (GREEN open). Action: JC to poke JC; deadline by next teleconference....
|JC
|JC to poke JC; deadline by next teleconference.
|Done
|-
|[https://sourceforge.net/p/tei/feature-requests/475/ FR 475] Stop using attributes to store space-delimited values (GREEN open). Nothing wrong with space-delimit...
|JC
|JC to Close as Closed-rejected.
|Done
|-
|[https://sourceforge.net/p/tei/feature-requests/401/ FR 401] extend and clarify use of particDesc and settingDesc (GREEN open). JC admits sloth and will implemen...
|JC
|JC to implement before next teleconference; Council decides it might be better to add these (model.
|Done
|-
|[http://sourceforge.net/p/tei/feature-requests/378/ FR 378] ; c.f. A Generic Formalism for Encoding Standoff annotations in TEI). Action: JC to ask Peter Stadle...
|JC, HC, SB
|JC to ask Peter Stadler if he’d like to attend as Council rep; otherwise any interested members of Council (HC,SB) are encouraged to attend virtually.
|Done
|-
|[https://sourceforge.net/p/tei/bugs/229/ BUG 229] Check desc of all xs:anyURI atts for in-doc restrictions (GREEN pending). We got rid of data.code al...
|JC
|JC to check prose discussion all xsd:anyURI attributes by next teleconference.
|pending
|-
|[https://sourceforge.net/p/tei/bugs/336/ BUG 336] AdBlock blocks 'msad' ID (GREEN pending-later). Per last comment, time has passed and nothing else h...
|JC
|JC to close ticket.
|Done
|-
|[https://sourceforge.net/p/tei/bugs/587/ BUG 587] Guidelines version info on pages should link better (GREEN open). Action: JC to carry out his last c...
|JC
|JC to carry out his last comment on the ticket.
|not done
|-
|[https://sourceforge.net/p/tei/bugs/519/ BUG 519] Make lb, pb, cb, gb consistent (GREEN open-accepted). Council decided to close. Action: JC to close ...
|JC
|JC to close [DONE].
|Done
|-
|[https://sourceforge.net/p/tei/bugs/525/ BUG 525] citedRange and biblScope should share att class (GREEN open). SB admitted to sloth. Action: SB to co...
|MH, JC, KH
|MH to check Allura settings to make sure that the owners of both bugs and feature requests receive email notifications. [JC and KH looked into this during a break and might have fixed it through another mechanism. MH to check with JC].
|unsure
|-
|[https://sourceforge.net/p/tei/bugs/418/ BUG 418] Names and Dates chapter does not mention calendar (GREEN open). Action: JC will add the prose before...
|JC
|JC will add the prose before the next teleconference.
|not done
|}

===Actions for Kevin Hawkins===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|[https://sourceforge.net/p/tei/feature-requests/457/ FR 457] : KH: In the ticket I want to clarify what you use tagUsage for and what to put in a project-specifi...
|KH, LB, JC
|KH, LB, and JC will review and make a recommendation to Council before the next face-to-face.
|Discussion happening on ticket.
|-
|[https://sourceforge.net/p/tei/feature-requests/384/ FR 384] that once 384 is implemented, we’ll add a note on att.typed reminding people that this is meant for ...
|HC, KH
|HC will implement [DONE]. KH will add a comment to FR 384 [DONE].
|done during Council meeting
|-
|[https://sourceforge.net/p/tei/feature-requests/468/ FR 468] : HC: precision expresses false precision that’s not real probability. It’s something more like cert...
|KH
|KH to add to the deprecation document the requirement to announce to the community that we plan to deprecate something and to get in touch if you object.
|done 2013-12-26
|-
|[https://sourceforge.net/p/tei/feature-requests/383/ FR 383] where to put idno within biblStruct? (AMBER open) This is one of three tickets where KH could not fi...
|KH, SB
|KH will create a new ticket pointing to this and the other two tickets with deprecation problems (as listed on the wiki) saying we need a way to deprecate members of content model and reassign to SB to solve the three tickets using a Schematron warning, and to add @validUntil on constraintSpec.
|done 2013-12-08 (new ticket is at https://sourceforge.net/p/tei/feature-requests/486/)
|-
|[https://sourceforge.net/p/tei/feature-requests/482/ FR 482] The term strikes back - terminology chapter (AMBER open). The ISO is working on a standard for termi...
|LB, KH, SB
|LB, KH and SB to articulate a more generic policy for TEI on the integration of external standards and will generate a one-page proposal for this policy. This should be provided to Council ahead of the next teleconference. In addition, LB, KH, and SB will check with Laurent that he wants TBX incorporated into the Guidelines as is or kept in sync in the future and what he thinks about melding into the rest of the TEI Guidelines (in language, approach, element naming conventions) or keeping it self-contained.
|Kevin drafted a [http://www.tei-c.org/Activities/Council/Working/tcw28.xml generic policy] and circulated to Lou and Syd on 2013-12-26. Discussion of whether to incorporate TBX into the Guidelines is [http://sourceforge.net/p/tei/feature-requests/482/#28f3 happening on ticket].
|-
|[https://sourceforge.net/p/tei/feature-requests/294/ FR 294] altIdentifier is deprecated within msPart (AMBER open). Action: KH to change to Green and add to the...
|KH
|KH to change to Green and add to the ticket about deprecation using Schematron along with 383, if not already done.
|done 2013-12-08
|-
|[https://sourceforge.net/p/tei/bugs/528/ BUG 528] consistency in "the Guidelines" vs. "these Guidelines" (AMBER open). This should be green. Action: K...
|KH
|KH to do this.
|
|-
|[https://sourceforge.net/p/tei/bugs/548/ BUG 548] use of modal verbs in Guidelines (AMBER pending-later). Already assigned to KH. RW agreed to help. I...
|KH, RW, LB
|KH and RW to create a new, detailed ticket with all questionable cases. In the meantime, LB will fix the edits that KH made at r12525.
|LB commented out otiose paragraph.
|-
|[https://sourceforge.net/p/tei/bugs/216/ BUG 216] half title pages in TEI Tite (AMBER open-postponed). KH has to finish comparing TEI-Tite with the Ap...
|KH
|KH to resolve Tite problems and report regularly to Council on progress.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/280/ FR 280] clarification of colloc (GREEN pending-accepted). #1 is already done. #2: Breakout group agreed that...
|KH
|KH to remove @type from both examples, etc.
|done 2013-12-26
|-
|[https://sourceforge.net/p/tei/feature-requests/482/ FR 482] Earlier we decided:Action: LB, KH and SB to articulate a more generic policy for TEI on the integrat...
|LB, KH, SB
|LB, KH and SB to articulate a more generic policy for TEI on the integration of external standards and will generate a one-page proposal for this policy. This should be provided to Council ahead of the next teleconference. In addition, LB, KH, and SB will check with Laurent that he wants TBX incorporated into the Guidelines as is or kept in sync in the future and what he thinks about melding into the rest of the TEI Guidelines (in language, approach, element naming conventions) or keeping it self-contained.
|Kevin drafted a [http://www.tei-c.org/Activities/Council/Working/tcw28.xml generic policy] and circulated to Lou and Syd on 2013-12-26. Discussion of whether to incorporate TBX into the Guidelines is [http://sourceforge.net/p/tei/feature-requests/482/#28f3 happening on ticket].
|-
|[https://sourceforge.net/p/tei/bugs/525/ BUG 525] citedRange and biblScope should share att class (GREEN open). SB admitted to sloth. Action: SB to co...
|MH, JC, KH
|MH to check Allura settings to make sure that the owners of both bugs and feature requests receive email notifications. [JC and KH looked into this during a break and might have fixed it through another mechanism. MH to check with JC].
|n/a
|}

===Actions for Martin Holmes===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|[https://sourceforge.net/p/tei/feature-requests/453/ FR 453] a place for metadata that you can't fit into existing header elements AMBER open Discussion talks mo...
|MH, PS, LB
|MH will offer DC examples and PS will offer MARC examples. LB will pull them together into some text to be inserted into the Guidelines. Given this, Council will reconsider the feature request and whether to create the wrapper element.
|Examples provided 2013-11-20
|-
|[https://sourceforge.net/p/tei/feature-requests/471/ FR 471] extend the possible usages of argument (AMBER open). (If the intended use case is encoder-supplied a...
|LB, MH
|
|Done. Fourth example added in rev 12666 2013-11-27.
|-
|[https://sourceforge.net/p/tei/feature-requests/472/ FR 472] docDate in dateline ? EM: dateline does not allow docDate, but byline allows docAuthor. This is inco...
|MH
|MH to add docDate to dateline, and clarify with usage notes.
|Done 2013-11
|-
|[https://sourceforge.net/p/tei/feature-requests/443/ FR 443] @resp should be a member of att.global AMBER open. JC and SR: Global attributes should really not be...
|MH, LB
|MH and LB to agree on clarification to Guidelines to say that @resp means different things: responsibility for markup and content except when the element in question is a transcriptional element, in which case the content of the element is marked as coming from the source.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/303/ FR 303] check the apache logs for frequent 404s (AMBER open). Action: JC to ask DS to make the TEI-C webserv...
|JC, MH
|JC to ask DS to make the TEI-C webserver logs available somewhere we can see them; then action on MH to write script to generate lists of bad links of various types. JC also to check google analytics/Webmaster tools. Deadline to report back by next conference call.
|I've checked through the logs, which the webmaster provided for me. There seem to be no instances of systematic errors. There seems to be little to gain from this, assuming the sysadmins are already routine monitoring.
|-
|[https://sourceforge.net/p/tei/feature-requests/470/ FR 470] att.measurement and att.dimensions overlap (AMBER open). We are not really sure why all of these att...
|MH
|MH to move @commodity into its own class, and move measure and measureGrp to att.dimensions. Ticket to GREEN, assign to MH. [Subsequent study suggests to MH that this may be more complicated than it seems, and may have to wait on our having the ability to override valLists in attributes from attribute classes at the element level.]
|Set back to Amber pending further discussion. See ticket for details.
|-
|[http://wiki.tei-c.org/index.php/Council_agenda_2013-11#More_Details_on_Agenda_topics bottom of wiki agenda page] ) SR: Why are we proposing using alpha and beta? MH: Because we were proposing asking the community ...
|MH, SR
|Assign MH to update the release documentation re alpha and beta, and investigate how we might add the SVN last changed date and the rev number to the bottom of pages.
|Latter bit done by SR 2013-11-14. Documentation in TCW22 updated by MH 2013-11-14.
|-
|[https://sourceforge.net/p/tei/feature-requests/405/ FR 405] Wrong schema generated (AMBER pending-accepted). This is due to a bug in the current version in Roma...
|MH
|MH to see if it has been fixed, and if so, close the ticket.
|Done 2013-11
|-
|[https://sourceforge.net/p/tei/feature-requests/342/ FR 342] [http://wiki.tei-c.org/index.php/Text_Directionality_Draft first draft of new Guidelines sections] and questions [MH] MH summarized the genesis of this text from Providence.
|MH, LB
|Entire Council to (re)read MH’s draft before next face-to-face meeting. Once we’ve done that and agreed, someone will rewrite chapter 5 (WD) to include MH’s draft and the current section 10.6.6. LB volunteered.
|Council and the WG members have been asked to read and comment on the draft (2013-11-28).
|-
|[https://sourceforge.net/p/tei/bugs/578/ BUG 578] partial and recursive segmentation of s-units (AMBER open). [The Guidelines text is clear enough. Th...
|MH
|MH will revise content model to match the prose.
|Done 2013-11-27, although I really don't like the results of this.
|-
|[https://sourceforge.net/p/tei/feature-requests/298/ BUG 298] att.editLike should not bring att.dimensions & att.ranging (AMBER open-accepted). [MH to ask Gabriel...
|MH
|MH to ask Gabby to implement.
|GB has asked to pass the ticket to MH (2013-11-28). MH to create a full proposal and implement if approved.
|-
|[https://sourceforge.net/p/tei/feature-requests/212/ FR 212] Generic dating class (AMBER pending-accepted). Gabby claimed in 2011 that it’s done except needs som...
|HC, MH
|HC to investigate whether it’s actually been done. MH offered examples if needed.
|
|-
|[https://sourceforge.net/p/tei/bugs/568/ BUG 568] "How to edit the Guidelines" and chapter organization (AMBER open). SR: What MH found looks distinct...
|MH
|MH to replace references to entity references with explanation of XIncludes in “How to edit the Guidelines”.
|Done 2013-11
|-
|[https://sourceforge.net/p/tei/bugs/506/ BUG 506] Meaning of @corresp rather in dispute (AMBER open). Working group triage: needs to be discussed: Is ...
|MH
|MH to create an example and run it by tei-council before adding to the Guidelines.
|Done 2013-12-23
|-
|[https://sourceforge.net/p/tei/bugs/582/ BUG 582] Need for consistency in terminology relating to TEI conformance (AMBER open). Working group: Agreed ...
|MH
|MH to deal with the ticket narrowly, using a hyphen and lowercase but leaving both “conformant” and “conformable”.
|Done 2013-11-20
|-
|[https://sourceforge.net/p/tei/bugs/460/ BUG 460] list/@type="unordered" is not recommended, but used often (AMBER open). Working group: This bug has...
|MH
|MH to follow the last comment on ticket to figure out our current situation.
|Research done, and a proposal being developed [http://wiki.tei-c.org/index.php/List_types_and_rendering on the wiki].
|-
|[https://sourceforge.net/p/tei/bugs/581/ BUG 581] `attRef` needs better documentation (AMBER open). Action: SR to implement either removal of attRef, ...
|SR, MH
|SR to implement either removal of attRef, MH to adjust documentation.
|SR recommends holding off on documentation because he may be able to eliminate attRef in favour of classRef.
|-
|[https://sourceforge.net/p/tei/feature-requests/432/ FR 432] Change regex flavor on @matchPattern (GREEN open). Agreed, XPath. Action: MH Write to TEI-L list, if...
|MH
|MH Write to TEI-L list, if no negative feedback, change.
|Done 2013-11-21 rev 12660
|-
|[https://sourceforge.net/p/tei/bugs/312/ BUG 312] i18n revision due (GREEN open). Action: MH, when he completes action on related ticket (perhaps afte...
|MH
|MH, when he completes action on related ticket (perhaps after moving notes from minutes into tickets), to update this ticket.
|Some contacts made with potential translators 2013-12; suggestion for a pilot project with Italian and Chinese posted to Council list.
|-
|[https://sourceforge.net/p/tei/bugs/442/ BUG 442] update ODD documentation on www.tei-c.org and in Guidelines (GREEN open). Action: MH to finish it....
|MH
|MH to finish it.
|
|-
|[https://sourceforge.net/p/tei/bugs/441/ BUG 441] fDecl doesn't allow att.datcat yet (GREEN open-accepted). Action: MH to prod Piotr....
|MH
|MH to prod Piotr.
|Piotr prodded 2013-11-21, and twice more after that.
|-
|[https://sourceforge.net/p/tei/bugs/525/ BUG 525] citedRange and biblScope should share att class (GREEN open). SB admitted to sloth. Action: SB to co...
|MH, JC, KH
|MH to check Allura settings to make sure that the owners of both bugs and feature requests receive email notifications. [JC and KH looked into this during a break and might have fixed it through another mechanism. MH to check with JC].
|According to investigation, we've done what we can with Allura settings here.
|}

===Actions for Elli Mylonas===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|Ideas on how to run an experimental TEI Hackathon [SR]

|JC, HC, SR, EM
|JC to approach the DH 2014 committee and find out how they would prefer us to do it, and whether it’s a good idea; and tell the Board that HC, SR and EM are prepared to be involved in organizing this along with one or more Board members.
|
|-
|Ideas on how to run an experimental TEI Hackathon [SR]

|EM
|EM to make sure this happens.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/300/ FR 300] Move witStart et al. to model.milestoneLike (AMBER pending). Action: EM to change to red and assigne...
|EM
|EM to change to red and assigned to EM to chase up or otherwise close ticket.
|
|-
|[https://sourceforge.net/p/tei/bugs/594/ BUG 594] TEI-C website menu points to wrong index page for Guidelines (AMBER open). Fixed, will appear in nex...
|EM
|EM to create a ticket on the Chrome problem.
|
|-
|[https://sourceforge.net/p/tei/bugs/589/ BUG 589] add respons and space to att.responsibility (AMBER open). Working group triage: Is it ok to add have...
|EM
|EM will get rid of locally assigned @resp by adding to att.responsibility (thereby getting @cert as well). Will change to GREEN.
|
|-
|[https://sourceforge.net/p/tei/bugs/563/ BUG 563] inconsistent encoding of citations to sources of examples (AMBER open). Working group recommends ass...
|BB, EM, PS
|BB, EM, and PS to work on the ticket by mid-February 2014.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/389/ FR 389] clarify definition of @from on locus and biblScope (GREEN open). EM admits to sloth and will do so. ...
|EM
|EM to do before next teleconference.
|
|-
|[http://wiki.tei-c.org/index.php/TEI_Cheatsheets Cheatsheets: Short best/recommended practice documents] EM: Not cheatsheets - negative implication. RW: Quick Start. HC: Quick Reference; SB: “Guidelettes” ...
|EM
|EM to ask MB to clarify what she wants from Council with regard to helping cheatsheets.
|
|}

===Actions for Sebastian Rahtz===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|[http://tei.oucs.ox.ac.uk/EEBO/ http://tei.oucs.ox.ac.uk/EEBO/] for summary of problem, and links to tickets) SR: EEBO-TCP is a gigantic resource that claims to be ...
|SR
|SR will implement the schema change of adding @place to stage and will document and provide an example.
|adding @place. example to do
|-
|[https://sourceforge.net/p/tei/feature-requests/479/ FR 479] Adding the @place attribute to head and seg AMBER open JC noted that head is not meta-textual or in ...
|SR
|SR to take the ticket, and get more examples from the submitter
|DONE
|-
|[https://sourceforge.net/p/tei/feature-requests/445/ FR 445] Conversion of ODD to HTML: Examples should be aware of element renaming closed-fixed, implemented by...
|SR
|SR to add gi and att renaming to complete the ticket.
| COMPLETED FOR gi. Not possible for att.
|-
|[https://sourceforge.net/p/tei/feature-requests/442/ FR 442] Allow foreign to contain q (AMBER open). The group felt this should be rejected. Action:SR to close ...
|SR
|SR to close ticket because it’s rejected
|DONE
|-
|[https://sourceforge.net/p/tei/feature-requests/433/ FR 433] loosen content model of salute (AMBER open). SR: Underlying this was a desire for symmetry between s...
|SR
|SR will carry this out
|DONE
|-
|[https://sourceforge.net/p/tei/feature-requests/477/ FR 477] lines of poetry inside trailer (AMBER open). The request is for symmetry between head and trailer. T...
|SR
|SR to find a good way to achieve this, since what was done before with head was rather strange.
|DONE. Have copied what was done with head
|-
|[https://sourceforge.net/p/tei/feature-requests/383/ FR 383] where to put idno within biblStruct? (AMBER open) This is one of three tickets where KH could not fi...
|SR
|SR to check how @validUntil makes the build fail when out of date, and if necessary update this mechanism so it can handle @validUntil on constraintSpec. Ticket 383 will wait on all this, along with the two other tickets.
|DONE. It applies to tei:*[@validUntil], so should just work.] .
|-
|[http://wiki.tei-c.org/index.php/Council_agenda_2013-11#More_Details_on_Agenda_topics bottom of wiki agenda page] ) SR: Why are we proposing using alpha and beta? MH: Because we were proposing asking the community ...
|MH, SR
|Assign MH to update the release documentation re alpha and beta, and investigate how we might add the SVN last changed date and the rev number to the bottom of pages.
|Latter bit done by SR 2013-11-14. Documentation in TCW22 updated by MH 2013-11-14.]
|-
|Ideas on how to run an experimental TEI Hackathon [SR]
|JC, HC, SR, EM
|JC to approach the DH 2014 committee and find out how they would prefer us to do it, and whether it’s a good idea; and tell the Board that HC, SR and EM are prepared to be involved in organizing this along with one or more Board members.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/345/ FR 345] members of model.respLike should be members of att.declarable (AMBER open-later). Breakout group ins...
|SR
|SR to make the ticket Green and go ahead and implement it, including some documentation/examples.
|DONE
|-
|[https://sourceforge.net/p/tei/bugs/302/ BUG 302] version ignores @source (AMBER open). This is a Roma issue. Recommend marking as closed won’t fix be...
|SR
|SR to try reproducing this and set as closed-won’t fix.
|DONE
|-
|[https://sourceforge.net/p/tei/bugs/583/ BUG 583] Adding new attribute fails in Roma schema generation (AMBER open). Same as 302. Action: SR wil set a...
|SR
|SR wil set as closed-won’t fix and check that it has the Roma tag.
|DONE
|-
|[https://sourceforge.net/p/tei/bugs/434/ BUG 434] issues with ePub conversion (2/3) (AMBER open). Any issue not dealing with ODD processing should be ...
|SR
|SR will ask poster kindly to post there (explaining why) and close this issue.
|DONE
|-
|[https://sourceforge.net/p/tei/bugs/581/ BUG 581] `attRef` needs better documentation (AMBER open). Action: SR to implement either removal of attRef, ...
|SR, MH
|SR to implement either removal of attRef, MH to adjust documentation.
|FIxed attRef. thinking about classRef
|-
|[https://sourceforge.net/p/tei/feature-requests/467/ FR 467] Make @name optional on tei:relation (GREEN open). Action: SR has already done this....
|SR
|SR to action
|DOne
|-
|[https://sourceforge.net/p/tei/feature-requests/478/ FR 478] loosening content and model of `signed` (GREEN open). Agree that is is green. Though would model.div...
|SR
|SR to implement signed at top as well as bottom
|DONE
|}

===Actions for Paul Schaffner===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|[https://sourceforge.net/p/tei/feature-requests/453/ FR 453] a place for metadata that you can't fit into existing header elements AMBER open Discussion talks mo...
|MH, PS, LB
|MH will offer DC examples and PS will offer MARC examples. LB will pull them together into some text to be inserted into the Guidelines. Given this, Council will reconsider the feature request and whether to create the wrapper element.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/360/ FR 360] New attribute @keepHyphen. Ticket open, ticket GREEN, it’s rejected throughout the comments....
|PS
|PS to provide an example of the mechanism recommended to handle the use-case.
|
|-
|[https://sourceforge.net/p/tei/bugs/563/ BUG 563] inconsistent encoding of citations to sources of examples (AMBER open). Working group recommends ass...
|BB, EM, PS
|BB, EM, and PS to work on the ticket by mid-February 2014.
|
|-
|[https://sourceforge.net/p/tei/bugs/558/ BUG 558] name/orgName (AMBER open). Action: RW to ask PS where he is on this; change ticket status to GREEN....
|RW, PS
|RW to ask PS where he is on this; change ticket status to GREEN.
|
|}

===Actions for Torsten Schassan===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|

|TS
|TS to come up with a more detailed problem description and what the WG should attempt to solve by 2014-01-01.
|
|}

===Actions for Rebecca Welzenbach===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|[https://sourceforge.net/p/tei/feature-requests/384/ FR 384] : In April RW made a spreadsheet showing which elements she recommends moving into att.typed. And in...
|SB, RW
|SB and RW will review the list again.
|
|-
|Attributes without examples

|BB, RW
|BB and RW to turn into bug reports those attributes that are without examples that are high priority or need new/updated definitions.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/377/ FR 377] retaining punctuation marks in the text of a TEI document (AMBER open-accepted). RW says she has add...
|RW
|RW to finish the work and ask for help if necessary.
|
|-
|[https://sourceforge.net/p/tei/bugs/548/ BUG 548] use of modal verbs in Guidelines (AMBER pending-later). Already assigned to KH. RW agreed to help. I...
|KH, RW, LB
|KH and RW to create a new, detailed ticket with all questionable cases. In the meantime, LB will fix the edits that KH made at r12525.
|
|-
|[https://sourceforge.net/p/tei/bugs/558/ BUG 558] name/orgName (AMBER open). Action: RW to ask PS where he is on this; change ticket status to GREEN....
|RW, PS
|RW to ask PS where he is on this; change ticket status to GREEN.
|
|-
|[https://sourceforge.net/p/tei/bugs/401/ BUG 401] Most attributes lack good examples (GREEN open-accepted). This was previously discussed. Action: RW ...
|RW
|RW to follow up.
|
|}

[[Category:Council]]

Oxford2013-Actions2

2014-01-05T19:14:55Z

Hcayless: /* Actions for Hugh Cayless */

==Council Actions from November 2013 Oxford Meeting==

A list of actions, those responsible, and what has been done about them from [http://www.tei-c.org/Activities/Council/Meetings/tcm56.xml Oxford 2013 face to face meeting] of TEI Technical Council

===Actions for Brett Barney===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|Attributes without examples

|BB, RW
|BB and RW to turn into bug reports those attributes that are without examples that are high priority or need new/updated definitions.
|
|-
|[https://sourceforge.net/p/tei/bugs/563/ BUG 563] inconsistent encoding of citations to sources of examples (AMBER open). Working group recommends ass...
|BB, EM, PS
|BB, EM, and PS to work on the ticket by mid-February 2014.
|
|-
|[https://sourceforge.net/p/tei/bugs/610/ BUG 610] "lem" used in a confusing way in CriticalApparatus.xml (AMBER open). Action: BB to remove the last c...
|BB
|BB to remove the last clause of the sentence in question, beginning ", or to make clear".
|Done 2013-11-13
|-
|[https://sourceforge.net/p/tei/bugs/387/ BUG 387] clarifying heading or title of a graphic (GREEN open). LB recently posted a comment approving of the...
|BB
|BB will implement the ticket.
|Done 2013-11-13
|}

===Actions for Lou Burnard===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|[https://sourceforge.net/p/tei/feature-requests/457/ FR 457] : KH: In the ticket I want to clarify what you use tagUsage for and what to put in a project-specifi...
|KH, LB, JC
|KH, LB, and JC will review and make a recommendation to Council before the next face-to-face.
|KH emailed the others on 2013-12-26; LB updated ticket and emailed the others 2014-01-05
|-
|[https://sourceforge.net/p/tei/feature-requests/453/ FR 453] a place for metadata that you can't fit into existing header elements AMBER open Discussion talks mo...
|MH, PS, LB
|MH will offer DC examples and PS will offer MARC examples. LB will pull them together into some text to be inserted into the Guidelines. Given this, Council will reconsider the feature request and whether to create the wrapper element.
|Added comment on ticket suggesting that the proposal seems doomed to be rejected; action to explain how to handle this situation in the Guidelines remains open.
|-
|[https://sourceforge.net/p/tei/feature-requests/471/ FR 471] extend the possible usages of argument (AMBER open). (If the intended use case is encoder-supplied a...
|LB, MH
|New element <abstract> added; examples added .
|Done 2013-11-12
|-
|Pure ODD

|LB
|LB to add the new elements and the documentation ahead of the next release; documentation need only be at the element level, along with some brief introduction in the Guidelines, to be expanded to a full section later.
|First pass completed 2013-12-01
|-
|[https://sourceforge.net/p/tei/feature-requests/443/ FR 443] @resp should be a member of att.global AMBER open. JC and SR: Global attributes should really not be...
|MH, LB
|MH and LB to agree on clarification to Guidelines to say that @resp means different things: responsibility for markup and content except when the element in question is a transcriptional element, in which case the content of the element is marked as coming from the source.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/366/ FR 366] rationalize content models of org and place (etc) (AMBER open). Group thinks a small group of people...
|JC, LB, SB
|JC to make ticket red, should stay with JC, and he should initiate the process, working with LB and SB.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/458/ FR 458] Make listBibl and model.biblLike member of model.personPart (AMBER open). Lou has already done items...
|LB
|close the ticket.
|Done
|-
|i18n: take forward updating translations

|LB
|LB to testdrive the spreadsheet.
|Done
|-
|[https://sourceforge.net/p/tei/feature-requests/482/ FR 482] The term strikes back - terminology chapter (AMBER open). The ISO is working on a standard for termi...
|LB, KH, SB
|LB, KH and SB to articulate a more generic policy for TEI on the integration of external standards and will generate a one-page proposal for this policy. This should be provided to Council ahead of the next teleconference. In addition, LB, KH, and SB will check with Laurent that he wants TBX incorporated into the Guidelines as is or kept in sync in the future and what he thinks about melding into the rest of the TEI Guidelines (in language, approach, element naming conventions) or keeping it self-contained.
|Kevin drafted a [http://www.tei-c.org/Activities/Council/Working/tcw28.xml generic policy] and circulated to Lou and Syd on 2013-12-26. Discussion of whether to incorporate TBX into the Guidelines is [http://sourceforge.net/p/tei/feature-requests/482/#28f3 happening on ticket].
|-
|[https://sourceforge.net/p/tei/feature-requests/480/ FR 480] Adding the @hand attribute to all (or most) text-containing elements (AMBER open). Breakout group wa...
|LB
|LB to respond to the ticket FR 480.
|
|-
|[http://wiki.tei-c.org/index.php/Text_Directionality_Draft first draft of new Guidelines sections] and questions [MH] MH summarized the genesis of this text from Providence. He noted that not only th...
|MH, LB
|Entire Council to (re)read MH’s draft before next face-to-face meeting. Once we’ve done that and agreed, someone will rewrite chapter 5 (WD) to include MH’s draft and the current section 10.6.6. LB volunteered.
|
|-
|[https://sourceforge.net/p/tei/bugs/548/ BUG 548] use of modal verbs in Guidelines (AMBER pending-later). Already assigned to KH. RW agreed to help. I...
|KH, RW, LB
|KH and RW to create a new, detailed ticket with all questionable cases. In the meantime, LB will fix the edits that KH made at r12525.
|Commented out otiose paragraph.
|-
|[https://sourceforge.net/p/tei/bugs/468/ BUG 468] Order of elements in publicationStmt (AMBER open-accepted). Group discussion: SB: Despite Lou’s comm...
|SB, LB
|SB will do the content model and LB will do the prose. They’ll work out the specifics.
|Emailed syd 2014-01-05
|-
|[https://sourceforge.net/p/tei/feature-requests/469/ FR 469] add extent to att.dimensions (GREEN open). Agreed. Action: LB to provide an example in HD chapter (2...
|LB
|LB to provide an example in HD chapter (2.2.3) and close ticket.
|Done 2013-11-20
|-
|[https://sourceforge.net/p/tei/bugs/605/ BUG 605] clarifying add vs. supplied and del vs. surplus (AMBER open). Action: HC to emend the prose of the p...
|HC, LB
|HC to emend the prose of the paragraph beginning "The add element should not be used" to reference the surplus element also; LB points out that the specList can't be modified, because supplied/surplus aren't defined in Core.
|Done, I think.
|-
|[https://sourceforge.net/p/tei/bugs/609/ BUG 609] "lemma" used in a confusing way in CriticalApparatus.xml (AMBER open). Action: LB to remove the phra...
|LB
|LB to remove the phrase "on any one lemma" from the @varSeq description.
|Done, 2013-11-13
|-
|[https://sourceforge.net/p/tei/feature-requests/461/ FR 461] Two small improvements to `recording` (GREEN open). Action: LB to do this by next teleconference....
|LB
|LB to do this by next teleconference.
|Done 2013-11-13
|-
|[https://sourceforge.net/p/tei/feature-requests/482/ FR 482] Earlier we decided:Action: LB, KH and SB to articulate a more generic policy for TEI on the integrat...
|LB, KH, SB
|LB, KH and SB to articulate a more generic policy for TEI on the integration of external standards and will generate a one-page proposal for this policy. This should be provided to Council ahead of the next teleconference. In addition, LB, KH, and SB will check with Laurent that he wants TBX incorporated into the Guidelines as is or kept in sync in the future and what he thinks about melding into the rest of the TEI Guidelines (in language, approach, element naming conventions) or keeping it self-contained.
|Kevin drafted a [http://www.tei-c.org/Activities/Council/Working/tcw28.xml generic policy] and circulated to Lou and Syd on 2013-12-26. Discussion of whether to incorporate TBX into the Guidelines is [http://sourceforge.net/p/tei/feature-requests/482/#28f3 happening on ticket].
|-
|Correspondence SIG:

|SB, LB
|SB and LB would like to (re?-)join the task force. Council advises them to keep in mind the work by the Ontology/MS SIGs, in particular Torsten Schassan, on an ‘object’ or ‘objectDesc’ element.
|
|}

===Actions for Syd Bauman===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|[https://sourceforge.net/p/tei/feature-requests/384/ FR 384] : In April RW made a spreadsheet showing which elements she recommends moving into att.typed. And in...
|SB, RW
|SB and RW will review the list again.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/459/ FR 459] : This is just waiting for implementation....
|SB
|SB will implement by end of January 2014.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/481/ FR 481] check that all sibling att.translatable elements have @versionDate (AMBER open). (Agreed that siblin...
|SB
|SB to check whether this is implemented, and if not, get it implemented then close the ticket.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/468/ FR 468] : HC: precision expresses false precision that’s not real probability. It’s something more like cert...
|SB
|
|
|-
|[https://sourceforge.net/p/tei/feature-requests/383/ FR 383] where to put idno within biblStruct? (AMBER open) This is one of three tickets where KH could not fi...
|KH, SB
|KH will create a new ticket pointing to this and the other two tickets with deprecation problems (as listed on the wiki) saying we need a way to deprecate members of content model and reassign to SB to solve the three tickets using a Schematron warning, and to add @validUntil on constraintSpec.
|This ticket reassigned to Syd, and new ticket created: https://sourceforge.net/p/tei/feature-requests/486/ .
|-
|[https://sourceforge.net/p/tei/feature-requests/366/ FR 366] rationalize content models of org and place (etc) (AMBER open). Group thinks a small group of people...
|JC, LB, SB
|JC to make ticket red, should stay with JC, and he should initiate the process, working with LB and SB.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/482/ FR 482] The term strikes back - terminology chapter (AMBER open). The ISO is working on a standard for termi...
|LB, KH, SB
|LB, KH and SB to articulate a more generic policy for TEI on the integration of external standards and will generate a one-page proposal for this policy. This should be provided to Council ahead of the next teleconference. In addition, LB, KH, and SB will check with Laurent that he wants TBX incorporated into the Guidelines as is or kept in sync in the future and what he thinks about melding into the rest of the TEI Guidelines (in language, approach, element naming conventions) or keeping it self-contained.
|Kevin drafted a [http://www.tei-c.org/Activities/Council/Working/tcw28.xml generic policy] and circulated to Lou and Syd on 2013-12-26. Discussion of whether to incorporate TBX into the Guidelines is [http://sourceforge.net/p/tei/feature-requests/482/#28f3 happening on ticket].
|-
|[https://sourceforge.net/p/tei/bugs/276/ BUG 276] internationalisation links (AMBER open). Language links at bottom of a page should take you to same ...
|JC, SB
|JC to make Green and allocate to SB.
|
|-
|[https://sourceforge.net/p/tei/bugs/619/ BUG 619] tei_allPlus.rng: conflicting ID-types for attribute "id" of element "partialdiff" from namespace "ht...
|SB
|SB to double-check whether able to reproduce and report back on ticket if able to.
|
|-
|[https://sourceforge.net/p/tei/bugs/288/ BUG 288] deprecate use of gram except as a child of gramGrp (AMBER open-accepted). [This is pending creation ...
|SB
|SB to create the new ticket and write the Schematron for this particular deprecation.
|Elsewhere we decided that KH would create the new ticket, which he's done at https://sourceforge.net/p/tei/feature-requests/486/ . But SB still needs to solve this ticket.
|-
|[https://sourceforge.net/p/tei/bugs/468/ BUG 468] Order of elements in publicationStmt (AMBER open-accepted). Group discussion: SB: Despite Lou’s comm...
|SB, LB
|SB will do the content model and LB will do the prose. They’ll work out the specifics.
|
|-
|[https://sourceforge.net/p/tei/bugs/405/ BUG 405] XPointer schemes may not nest, but see ch. 16 (AMBER open). Action: SB to fix documentation....
|SB
|SB to fix documentation.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/482/ FR 482] Earlier we decided:Action: LB, KH and SB to articulate a more generic policy for TEI on the integrat...
|LB, KH, SB
|LB, KH and SB to articulate a more generic policy for TEI on the integration of external standards and will generate a one-page proposal for this policy. This should be provided to Council ahead of the next teleconference. In addition, LB, KH, and SB will check with Laurent that he wants TBX incorporated into the Guidelines as is or kept in sync in the future and what he thinks about melding into the rest of the TEI Guidelines (in language, approach, element naming conventions) or keeping it self-contained.
|Kevin drafted a [http://www.tei-c.org/Activities/Council/Working/tcw28.xml generic policy] and circulated to Lou and Syd on 2013-12-26. Discussion of whether to incorporate TBX into the Guidelines is [http://sourceforge.net/p/tei/feature-requests/482/#28f3 happening on ticket].
|-
|[http://sourceforge.net/p/tei/feature-requests/378/ FR 378] ; c.f. A Generic Formalism for Encoding Standoff annotations in TEI). Action: JC to ask Peter Stadle...
|JC, HC, SB
|JC to ask Peter Stadler if he’d like to attend as Council rep; otherwise any interested members of Council (HC,SB) are encouraged to attend virtually.
|
|-
|Correspondence SIG:

|SB, LB
|SB and LB would like to (re?-)join the task force. Council advises them to keep in mind the work by the Ontology/MS SIGs, in particular Torsten Schassan, on an ‘object’ or ‘objectDesc’ element.
|
|-
|[https://sourceforge.net/p/tei/bugs/525/ BUG 525] citedRange and biblScope should share att class (GREEN open). SB admitted to sloth. Action: SB to co...
|SB
|SB to complete.
|
|}

===Actions for Hugh Cayless===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|Report on specification and estimated cost for XPointer resolver [HC/SB]

|HC
|HC to report on XPointer resolver and whether we should progress it.
|Draft GLs revision posted on [http://hcayless.github.io/TEI-Guidelines/Guidelines-web/en/html/SA.html#SATS GitHub]
|-
|[https://sourceforge.net/p/tei/feature-requests/465/ FR 465] : Gabby and HC seem to agree on it, and the example looks sensible. LB’s comment could be raised as ...
|HC
|HC will implement before end of January 2014.
|Done.
|-
|[https://sourceforge.net/p/tei/feature-requests/384/ FR 384] that once 384 is implemented, we’ll add a note on att.typed reminding people that this is meant for ...
|HC, KH
|HC will implement [DONE]. KH will add a comment to FR 384 [DONE].
|done during Council meeting
|-
|[https://sourceforge.net/p/tei/feature-requests/462/ FR 462] idno@type='uri' for Linked Data AMBER open (We agreed. @type=”URI” alongside @type=”URL”) EM: The su...
|HC
|HC to implement this and close the ticket FR 462.
|Done.
|-
|[https://sourceforge.net/p/tei/feature-requests/468/ FR 468] : HC: precision expresses false precision that’s not real probability. It’s something more like cert...
|HC
|HC to email TEI-L.
|FR implemented at meeting and email sent.
|-
|Ideas on how to run an experimental TEI Hackathon [SR]

|JC, HC, SR, EM
|JC to approach the DH 2014 committee and find out how they would prefer us to do it, and whether it’s a good idea; and tell the Board that HC, SR and EM are prepared to be involved in organizing this along with one or more Board members.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/212/ FR 212] Generic dating class (AMBER pending-accepted). Gabby claimed in 2011 that it’s done except needs som...
|HC, MH
|HC to investigate whether it’s actually been done. MH offered examples if needed.
|
|-
|[https://sourceforge.net/p/tei/bugs/605/ BUG 605] clarifying add vs. supplied and del vs. surplus (AMBER open). Action: HC to emend the prose of the p...
|HC, LB
|HC to emend the prose of the paragraph beginning "The add element should not be used" to reference the surplus element also; LB points out that the specList can't be modified, because supplied/surplus aren't defined in Core.
|Done.
|-
|[http://sourceforge.net/p/tei/feature-requests/378/ FR 378] ; c.f. A Generic Formalism for Encoding Standoff annotations in TEI). Action: JC to ask Peter Stadle...
|JC, HC, SB
|JC to ask Peter Stadler if he’d like to attend as Council rep; otherwise any interested members of Council (HC,SB) are encouraged to attend virtually.
|
|}

===Actions for James Cummings===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|[https://sourceforge.net/p/tei/feature-requests/457/ FR 457] : KH: In the ticket I want to clarify what you use tagUsage for and what to put in a project-specifi...
|KH, LB, JC
|KH, LB, and JC will review and make a recommendation to Council before the next face-to-face.
|KH emailed the others on 2013-12-26.
|-
|[https://sourceforge.net/p/tei/feature-requests/476/ FR 476] use of stage inside poetry, and using placement attribute (AMBER open). (Council agreed to @place; s...
|JC
|JC to close ticket FR 476 noting it has been resolved.
|
|-
|[https://docs.google.com/document/d/1766WTJV2xcfANh8HRZW5m520yrC1nCzQJzUgKpwiylI/edit TEI Roma Replacement Specification] JC: The existing Roma is dated and flawed, as we all know. Many tickets have come up which we cannot...
|JC
|ALL Council to go through the proposal again and discuss it, remembering to look at the comments, and further refine it. JC to make sure it’s tidied up. Deadline: next teleconference.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/303/ FR 303] check the apache logs for frequent 404s (AMBER open). Action: JC to ask DS to make the TEI-C webserv...
|JC, MH
|JC to ask DS to make the TEI-C webserver logs available somewhere we can see them; then action on MH to write script to generate lists of bad links of various types. JC also to check google analytics/Webmaster tools. Deadline to report back by next conference call.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/305/ FR 305] Updating info on projects page (AMBER open). Project pages go out of date. There is a way to submit ...
|JC
|JC to ask DS to make that correction info available on each project page, along with its last-updated date if possible (and the latter should also show up on the bullet-point list).
|
|-
|[https://sourceforge.net/p/tei/feature-requests/466/ FR 466] Make it possible to add SIG labels to tickets (AMBER open). Action: JC as SIG Coordinator to tell th...
|JC
|JC as SIG Coordinator to tell the SIGs that if they wish, we can make their SIG convener a developer on SF and make it possible to assign SIG labels to tickets. Deadline: next teleconference.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/366/ FR 366] rationalize content models of org and place (etc) (AMBER open). Group thinks a small group of people...
|JC, LB, SB
|JC to make ticket red, should stay with JC, and he should initiate the process, working with LB and SB.
|
|-
|Ideas on how to run an experimental TEI Hackathon [SR]

|JC, HC, SR, EM
|JC to approach the DH 2014 committee and find out how they would prefer us to do it, and whether it’s a good idea; and tell the Board that HC, SR and EM are prepared to be involved in organizing this along with one or more Board members.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/264/ FR 264] altIdentifier in msPart (AMBER pending-accepted). Action: JC to change to Green and assign to himsel...
|JC
|JC to change to Green and assign to himself, then nudge Torsten for an example of an altIdentifier within an msPart.
|
|-
|[https://sourceforge.net/p/tei/bugs/276/ BUG 276] internationalisation links (AMBER open). Language links at bottom of a page should take you to same ...
|JC, SB
|JC to make Green and allocate to SB.
|
|-
|[https://sourceforge.net/p/tei/bugs/515/ BUG 515] Bad example of feature/@fVal (AMBER open). [Change this to RED as it’s not clear what needs changin...
|JC
|JC to check that’s been changed to RED [DONE].
|
|-
|[https://sourceforge.net/p/tei/bugs/582/ BUG 582] Need for consistency in terminology relating to TEI conformance (AMBER open). Working group: Agreed ...
|JC
|JC will create a ticket to reconsider the discussion of “conformable” and “conformant” in the Guidelines.
|
|-
|[https://sourceforge.net/p/tei/bugs/601/ BUG 601] att.patternReplacement/@matchPattern should be XPath regex, not XML Schema (AMBER open). Action: JC ...
|JC
|JC to close as a dupe of FR 432.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/460/ FR 460] Use of geogFeat in transcription? (GREEN open). Ok. Action: JC to do it before next teleconference....
|JC
|JC to do it before next teleconference.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/474/ FR 474] add an exemplum for @ref (GREEN open). Action: JC to poke JC; deadline by next teleconference....
|JC
|JC to poke JC; deadline by next teleconference.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/475/ FR 475] Stop using attributes to store space-delimited values (GREEN open). Nothing wrong with space-delimit...
|JC
|JC to Close as Closed-rejected.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/401/ FR 401] extend and clarify use of particDesc and settingDesc (GREEN open). JC admits sloth and will implemen...
|JC
|JC to implement before next teleconference; Council decides it might be better to add these (model.
|
|-
|[http://sourceforge.net/p/tei/feature-requests/378/ FR 378] ; c.f. A Generic Formalism for Encoding Standoff annotations in TEI). Action: JC to ask Peter Stadle...
|JC, HC, SB
|JC to ask Peter Stadler if he’d like to attend as Council rep; otherwise any interested members of Council (HC,SB) are encouraged to attend virtually.
|
|-
|[https://sourceforge.net/p/tei/bugs/229/ BUG 229] Check desc of all xs:anyURI atts for in-doc restrictions (GREEN pending). We got rid of data.code al...
|JC
|JC to check prose discussion all xsd:anyURI attributes by next teleconference.
|
|-
|[https://sourceforge.net/p/tei/bugs/336/ BUG 336] AdBlock blocks 'msad' ID (GREEN pending-later). Per last comment, time has passed and nothing else h...
|JC
|JC to close ticket.
|
|-
|[https://sourceforge.net/p/tei/bugs/587/ BUG 587] Guidelines version info on pages should link better (GREEN open). Action: JC to carry out his last c...
|JC
|JC to carry out his last comment on the ticket.
|
|-
|[https://sourceforge.net/p/tei/bugs/519/ BUG 519] Make lb, pb, cb, gb consistent (GREEN open-accepted). Council decided to close. Action: JC to close ...
|JC
|JC to close [DONE].
|
|-
|[https://sourceforge.net/p/tei/bugs/525/ BUG 525] citedRange and biblScope should share att class (GREEN open). SB admitted to sloth. Action: SB to co...
|MH, JC, KH
|MH to check Allura settings to make sure that the owners of both bugs and feature requests receive email notifications. [JC and KH looked into this during a break and might have fixed it through another mechanism. MH to check with JC].
|
|-
|[https://sourceforge.net/p/tei/bugs/418/ BUG 418] Names and Dates chapter does not mention calendar (GREEN open). Action: JC will add the prose before...
|JC
|JC will add the prose before the next teleconference.
|
|}

===Actions for Kevin Hawkins===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|[https://sourceforge.net/p/tei/feature-requests/457/ FR 457] : KH: In the ticket I want to clarify what you use tagUsage for and what to put in a project-specifi...
|KH, LB, JC
|KH, LB, and JC will review and make a recommendation to Council before the next face-to-face.
|Discussion happening on ticket.
|-
|[https://sourceforge.net/p/tei/feature-requests/384/ FR 384] that once 384 is implemented, we’ll add a note on att.typed reminding people that this is meant for ...
|HC, KH
|HC will implement [DONE]. KH will add a comment to FR 384 [DONE].
|done during Council meeting
|-
|[https://sourceforge.net/p/tei/feature-requests/468/ FR 468] : HC: precision expresses false precision that’s not real probability. It’s something more like cert...
|KH
|KH to add to the deprecation document the requirement to announce to the community that we plan to deprecate something and to get in touch if you object.
|done 2013-12-26
|-
|[https://sourceforge.net/p/tei/feature-requests/383/ FR 383] where to put idno within biblStruct? (AMBER open) This is one of three tickets where KH could not fi...
|KH, SB
|KH will create a new ticket pointing to this and the other two tickets with deprecation problems (as listed on the wiki) saying we need a way to deprecate members of content model and reassign to SB to solve the three tickets using a Schematron warning, and to add @validUntil on constraintSpec.
|done 2013-12-08 (new ticket is at https://sourceforge.net/p/tei/feature-requests/486/)
|-
|[https://sourceforge.net/p/tei/feature-requests/482/ FR 482] The term strikes back - terminology chapter (AMBER open). The ISO is working on a standard for termi...
|LB, KH, SB
|LB, KH and SB to articulate a more generic policy for TEI on the integration of external standards and will generate a one-page proposal for this policy. This should be provided to Council ahead of the next teleconference. In addition, LB, KH, and SB will check with Laurent that he wants TBX incorporated into the Guidelines as is or kept in sync in the future and what he thinks about melding into the rest of the TEI Guidelines (in language, approach, element naming conventions) or keeping it self-contained.
|Kevin drafted a [http://www.tei-c.org/Activities/Council/Working/tcw28.xml generic policy] and circulated to Lou and Syd on 2013-12-26. Discussion of whether to incorporate TBX into the Guidelines is [http://sourceforge.net/p/tei/feature-requests/482/#28f3 happening on ticket].
|-
|[https://sourceforge.net/p/tei/feature-requests/294/ FR 294] altIdentifier is deprecated within msPart (AMBER open). Action: KH to change to Green and add to the...
|KH
|KH to change to Green and add to the ticket about deprecation using Schematron along with 383, if not already done.
|done 2013-12-08
|-
|[https://sourceforge.net/p/tei/bugs/528/ BUG 528] consistency in "the Guidelines" vs. "these Guidelines" (AMBER open). This should be green. Action: K...
|KH
|KH to do this.
|
|-
|[https://sourceforge.net/p/tei/bugs/548/ BUG 548] use of modal verbs in Guidelines (AMBER pending-later). Already assigned to KH. RW agreed to help. I...
|KH, RW, LB
|KH and RW to create a new, detailed ticket with all questionable cases. In the meantime, LB will fix the edits that KH made at r12525.
|LB commented out otiose paragraph.
|-
|[https://sourceforge.net/p/tei/bugs/216/ BUG 216] half title pages in TEI Tite (AMBER open-postponed). KH has to finish comparing TEI-Tite with the Ap...
|KH
|KH to resolve Tite problems and report regularly to Council on progress.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/280/ FR 280] clarification of colloc (GREEN pending-accepted). #1 is already done. #2: Breakout group agreed that...
|KH
|KH to remove @type from both examples, etc.
|done 2013-12-26
|-
|[https://sourceforge.net/p/tei/feature-requests/482/ FR 482] Earlier we decided:Action: LB, KH and SB to articulate a more generic policy for TEI on the integrat...
|LB, KH, SB
|LB, KH and SB to articulate a more generic policy for TEI on the integration of external standards and will generate a one-page proposal for this policy. This should be provided to Council ahead of the next teleconference. In addition, LB, KH, and SB will check with Laurent that he wants TBX incorporated into the Guidelines as is or kept in sync in the future and what he thinks about melding into the rest of the TEI Guidelines (in language, approach, element naming conventions) or keeping it self-contained.
|Kevin drafted a [http://www.tei-c.org/Activities/Council/Working/tcw28.xml generic policy] and circulated to Lou and Syd on 2013-12-26. Discussion of whether to incorporate TBX into the Guidelines is [http://sourceforge.net/p/tei/feature-requests/482/#28f3 happening on ticket].
|-
|[https://sourceforge.net/p/tei/bugs/525/ BUG 525] citedRange and biblScope should share att class (GREEN open). SB admitted to sloth. Action: SB to co...
|MH, JC, KH
|MH to check Allura settings to make sure that the owners of both bugs and feature requests receive email notifications. [JC and KH looked into this during a break and might have fixed it through another mechanism. MH to check with JC].
|n/a
|}

===Actions for Martin Holmes===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|[https://sourceforge.net/p/tei/feature-requests/453/ FR 453] a place for metadata that you can't fit into existing header elements AMBER open Discussion talks mo...
|MH, PS, LB
|MH will offer DC examples and PS will offer MARC examples. LB will pull them together into some text to be inserted into the Guidelines. Given this, Council will reconsider the feature request and whether to create the wrapper element.
|Examples provided 2013-11-20
|-
|[https://sourceforge.net/p/tei/feature-requests/471/ FR 471] extend the possible usages of argument (AMBER open). (If the intended use case is encoder-supplied a...
|LB, MH
|
|Done. Fourth example added in rev 12666 2013-11-27.
|-
|[https://sourceforge.net/p/tei/feature-requests/472/ FR 472] docDate in dateline ? EM: dateline does not allow docDate, but byline allows docAuthor. This is inco...
|MH
|MH to add docDate to dateline, and clarify with usage notes.
|Done 2013-11
|-
|[https://sourceforge.net/p/tei/feature-requests/443/ FR 443] @resp should be a member of att.global AMBER open. JC and SR: Global attributes should really not be...
|MH, LB
|MH and LB to agree on clarification to Guidelines to say that @resp means different things: responsibility for markup and content except when the element in question is a transcriptional element, in which case the content of the element is marked as coming from the source.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/303/ FR 303] check the apache logs for frequent 404s (AMBER open). Action: JC to ask DS to make the TEI-C webserv...
|JC, MH
|JC to ask DS to make the TEI-C webserver logs available somewhere we can see them; then action on MH to write script to generate lists of bad links of various types. JC also to check google analytics/Webmaster tools. Deadline to report back by next conference call.
|I've checked through the logs, which the webmaster provided for me. There seem to be no instances of systematic errors. There seems to be little to gain from this, assuming the sysadmins are already routine monitoring.
|-
|[https://sourceforge.net/p/tei/feature-requests/470/ FR 470] att.measurement and att.dimensions overlap (AMBER open). We are not really sure why all of these att...
|MH
|MH to move @commodity into its own class, and move measure and measureGrp to att.dimensions. Ticket to GREEN, assign to MH. [Subsequent study suggests to MH that this may be more complicated than it seems, and may have to wait on our having the ability to override valLists in attributes from attribute classes at the element level.]
|Set back to Amber pending further discussion. See ticket for details.
|-
|[http://wiki.tei-c.org/index.php/Council_agenda_2013-11#More_Details_on_Agenda_topics bottom of wiki agenda page] ) SR: Why are we proposing using alpha and beta? MH: Because we were proposing asking the community ...
|MH, SR
|Assign MH to update the release documentation re alpha and beta, and investigate how we might add the SVN last changed date and the rev number to the bottom of pages.
|Latter bit done by SR 2013-11-14. Documentation in TCW22 updated by MH 2013-11-14.
|-
|[https://sourceforge.net/p/tei/feature-requests/405/ FR 405] Wrong schema generated (AMBER pending-accepted). This is due to a bug in the current version in Roma...
|MH
|MH to see if it has been fixed, and if so, close the ticket.
|Done 2013-11
|-
|[https://sourceforge.net/p/tei/feature-requests/342/ FR 342] [http://wiki.tei-c.org/index.php/Text_Directionality_Draft first draft of new Guidelines sections] and questions [MH] MH summarized the genesis of this text from Providence.
|MH, LB
|Entire Council to (re)read MH’s draft before next face-to-face meeting. Once we’ve done that and agreed, someone will rewrite chapter 5 (WD) to include MH’s draft and the current section 10.6.6. LB volunteered.
|Council and the WG members have been asked to read and comment on the draft (2013-11-28).
|-
|[https://sourceforge.net/p/tei/bugs/578/ BUG 578] partial and recursive segmentation of s-units (AMBER open). [The Guidelines text is clear enough. Th...
|MH
|MH will revise content model to match the prose.
|Done 2013-11-27, although I really don't like the results of this.
|-
|[https://sourceforge.net/p/tei/feature-requests/298/ BUG 298] att.editLike should not bring att.dimensions & att.ranging (AMBER open-accepted). [MH to ask Gabriel...
|MH
|MH to ask Gabby to implement.
|GB has asked to pass the ticket to MH (2013-11-28). MH to create a full proposal and implement if approved.
|-
|[https://sourceforge.net/p/tei/feature-requests/212/ FR 212] Generic dating class (AMBER pending-accepted). Gabby claimed in 2011 that it’s done except needs som...
|HC, MH
|HC to investigate whether it’s actually been done. MH offered examples if needed.
|
|-
|[https://sourceforge.net/p/tei/bugs/568/ BUG 568] "How to edit the Guidelines" and chapter organization (AMBER open). SR: What MH found looks distinct...
|MH
|MH to replace references to entity references with explanation of XIncludes in “How to edit the Guidelines”.
|Done 2013-11
|-
|[https://sourceforge.net/p/tei/bugs/506/ BUG 506] Meaning of @corresp rather in dispute (AMBER open). Working group triage: needs to be discussed: Is ...
|MH
|MH to create an example and run it by tei-council before adding to the Guidelines.
|Done 2013-12-23
|-
|[https://sourceforge.net/p/tei/bugs/582/ BUG 582] Need for consistency in terminology relating to TEI conformance (AMBER open). Working group: Agreed ...
|MH
|MH to deal with the ticket narrowly, using a hyphen and lowercase but leaving both “conformant” and “conformable”.
|Done 2013-11-20
|-
|[https://sourceforge.net/p/tei/bugs/460/ BUG 460] list/@type="unordered" is not recommended, but used often (AMBER open). Working group: This bug has...
|MH
|MH to follow the last comment on ticket to figure out our current situation.
|Research done, and a proposal being developed [http://wiki.tei-c.org/index.php/List_types_and_rendering on the wiki].
|-
|[https://sourceforge.net/p/tei/bugs/581/ BUG 581] `attRef` needs better documentation (AMBER open). Action: SR to implement either removal of attRef, ...
|SR, MH
|SR to implement either removal of attRef, MH to adjust documentation.
|SR recommends holding off on documentation because he may be able to eliminate attRef in favour of classRef.
|-
|[https://sourceforge.net/p/tei/feature-requests/432/ FR 432] Change regex flavor on @matchPattern (GREEN open). Agreed, XPath. Action: MH Write to TEI-L list, if...
|MH
|MH Write to TEI-L list, if no negative feedback, change.
|Done 2013-11-21 rev 12660
|-
|[https://sourceforge.net/p/tei/bugs/312/ BUG 312] i18n revision due (GREEN open). Action: MH, when he completes action on related ticket (perhaps afte...
|MH
|MH, when he completes action on related ticket (perhaps after moving notes from minutes into tickets), to update this ticket.
|Some contacts made with potential translators 2013-12; suggestion for a pilot project with Italian and Chinese posted to Council list.
|-
|[https://sourceforge.net/p/tei/bugs/442/ BUG 442] update ODD documentation on www.tei-c.org and in Guidelines (GREEN open). Action: MH to finish it....
|MH
|MH to finish it.
|
|-
|[https://sourceforge.net/p/tei/bugs/441/ BUG 441] fDecl doesn't allow att.datcat yet (GREEN open-accepted). Action: MH to prod Piotr....
|MH
|MH to prod Piotr.
|Piotr prodded 2013-11-21, and twice more after that.
|-
|[https://sourceforge.net/p/tei/bugs/525/ BUG 525] citedRange and biblScope should share att class (GREEN open). SB admitted to sloth. Action: SB to co...
|MH, JC, KH
|MH to check Allura settings to make sure that the owners of both bugs and feature requests receive email notifications. [JC and KH looked into this during a break and might have fixed it through another mechanism. MH to check with JC].
|According to investigation, we've done what we can with Allura settings here.
|}

===Actions for Elli Mylonas===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|Ideas on how to run an experimental TEI Hackathon [SR]

|JC, HC, SR, EM
|JC to approach the DH 2014 committee and find out how they would prefer us to do it, and whether it’s a good idea; and tell the Board that HC, SR and EM are prepared to be involved in organizing this along with one or more Board members.
|
|-
|Ideas on how to run an experimental TEI Hackathon [SR]

|EM
|EM to make sure this happens.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/300/ FR 300] Move witStart et al. to model.milestoneLike (AMBER pending). Action: EM to change to red and assigne...
|EM
|EM to change to red and assigned to EM to chase up or otherwise close ticket.
|
|-
|[https://sourceforge.net/p/tei/bugs/594/ BUG 594] TEI-C website menu points to wrong index page for Guidelines (AMBER open). Fixed, will appear in nex...
|EM
|EM to create a ticket on the Chrome problem.
|
|-
|[https://sourceforge.net/p/tei/bugs/589/ BUG 589] add respons and space to att.responsibility (AMBER open). Working group triage: Is it ok to add have...
|EM
|EM will get rid of locally assigned @resp by adding to att.responsibility (thereby getting @cert as well). Will change to GREEN.
|
|-
|[https://sourceforge.net/p/tei/bugs/563/ BUG 563] inconsistent encoding of citations to sources of examples (AMBER open). Working group recommends ass...
|BB, EM, PS
|BB, EM, and PS to work on the ticket by mid-February 2014.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/389/ FR 389] clarify definition of @from on locus and biblScope (GREEN open). EM admits to sloth and will do so. ...
|EM
|EM to do before next teleconference.
|
|-
|[http://wiki.tei-c.org/index.php/TEI_Cheatsheets Cheatsheets: Short best/recommended practice documents] EM: Not cheatsheets - negative implication. RW: Quick Start. HC: Quick Reference; SB: “Guidelettes” ...
|EM
|EM to ask MB to clarify what she wants from Council with regard to helping cheatsheets.
|
|}

===Actions for Sebastian Rahtz===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|[http://tei.oucs.ox.ac.uk/EEBO/ http://tei.oucs.ox.ac.uk/EEBO/] for summary of problem, and links to tickets) SR: EEBO-TCP is a gigantic resource that claims to be ...
|SR
|SR will implement the schema change of adding @place to stage and will document and provide an example.
|adding @place. example to do
|-
|[https://sourceforge.net/p/tei/feature-requests/479/ FR 479] Adding the @place attribute to head and seg AMBER open JC noted that head is not meta-textual or in ...
|SR
|SR to take the ticket, and get more examples from the submitter
|DONE
|-
|[https://sourceforge.net/p/tei/feature-requests/445/ FR 445] Conversion of ODD to HTML: Examples should be aware of element renaming closed-fixed, implemented by...
|SR
|SR to add gi and att renaming to complete the ticket.
| COMPLETED FOR gi. Not possible for att.
|-
|[https://sourceforge.net/p/tei/feature-requests/442/ FR 442] Allow foreign to contain q (AMBER open). The group felt this should be rejected. Action:SR to close ...
|SR
|SR to close ticket because it’s rejected
|DONE
|-
|[https://sourceforge.net/p/tei/feature-requests/433/ FR 433] loosen content model of salute (AMBER open). SR: Underlying this was a desire for symmetry between s...
|SR
|SR will carry this out
|DONE
|-
|[https://sourceforge.net/p/tei/feature-requests/477/ FR 477] lines of poetry inside trailer (AMBER open). The request is for symmetry between head and trailer. T...
|SR
|SR to find a good way to achieve this, since what was done before with head was rather strange.
|DONE. Have copied what was done with head
|-
|[https://sourceforge.net/p/tei/feature-requests/383/ FR 383] where to put idno within biblStruct? (AMBER open) This is one of three tickets where KH could not fi...
|SR
|SR to check how @validUntil makes the build fail when out of date, and if necessary update this mechanism so it can handle @validUntil on constraintSpec. Ticket 383 will wait on all this, along with the two other tickets.
|DONE. It applies to tei:*[@validUntil], so should just work.] .
|-
|[http://wiki.tei-c.org/index.php/Council_agenda_2013-11#More_Details_on_Agenda_topics bottom of wiki agenda page] ) SR: Why are we proposing using alpha and beta? MH: Because we were proposing asking the community ...
|MH, SR
|Assign MH to update the release documentation re alpha and beta, and investigate how we might add the SVN last changed date and the rev number to the bottom of pages.
|Latter bit done by SR 2013-11-14. Documentation in TCW22 updated by MH 2013-11-14.]
|-
|Ideas on how to run an experimental TEI Hackathon [SR]
|JC, HC, SR, EM
|JC to approach the DH 2014 committee and find out how they would prefer us to do it, and whether it’s a good idea; and tell the Board that HC, SR and EM are prepared to be involved in organizing this along with one or more Board members.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/345/ FR 345] members of model.respLike should be members of att.declarable (AMBER open-later). Breakout group ins...
|SR
|SR to make the ticket Green and go ahead and implement it, including some documentation/examples.
|DONE
|-
|[https://sourceforge.net/p/tei/bugs/302/ BUG 302] version ignores @source (AMBER open). This is a Roma issue. Recommend marking as closed won’t fix be...
|SR
|SR to try reproducing this and set as closed-won’t fix.
|DONE
|-
|[https://sourceforge.net/p/tei/bugs/583/ BUG 583] Adding new attribute fails in Roma schema generation (AMBER open). Same as 302. Action: SR wil set a...
|SR
|SR wil set as closed-won’t fix and check that it has the Roma tag.
|DONE
|-
|[https://sourceforge.net/p/tei/bugs/434/ BUG 434] issues with ePub conversion (2/3) (AMBER open). Any issue not dealing with ODD processing should be ...
|SR
|SR will ask poster kindly to post there (explaining why) and close this issue.
|DONE
|-
|[https://sourceforge.net/p/tei/bugs/581/ BUG 581] `attRef` needs better documentation (AMBER open). Action: SR to implement either removal of attRef, ...
|SR, MH
|SR to implement either removal of attRef, MH to adjust documentation.
|FIxed attRef. thinking about classRef
|-
|[https://sourceforge.net/p/tei/feature-requests/467/ FR 467] Make @name optional on tei:relation (GREEN open). Action: SR has already done this....
|SR
|SR to action
|DOne
|-
|[https://sourceforge.net/p/tei/feature-requests/478/ FR 478] loosening content and model of `signed` (GREEN open). Agree that is is green. Though would model.div...
|SR
|SR to implement signed at top as well as bottom
|DONE
|}

===Actions for Paul Schaffner===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|[https://sourceforge.net/p/tei/feature-requests/453/ FR 453] a place for metadata that you can't fit into existing header elements AMBER open Discussion talks mo...
|MH, PS, LB
|MH will offer DC examples and PS will offer MARC examples. LB will pull them together into some text to be inserted into the Guidelines. Given this, Council will reconsider the feature request and whether to create the wrapper element.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/360/ FR 360] New attribute @keepHyphen. Ticket open, ticket GREEN, it’s rejected throughout the comments....
|PS
|PS to provide an example of the mechanism recommended to handle the use-case.
|
|-
|[https://sourceforge.net/p/tei/bugs/563/ BUG 563] inconsistent encoding of citations to sources of examples (AMBER open). Working group recommends ass...
|BB, EM, PS
|BB, EM, and PS to work on the ticket by mid-February 2014.
|
|-
|[https://sourceforge.net/p/tei/bugs/558/ BUG 558] name/orgName (AMBER open). Action: RW to ask PS where he is on this; change ticket status to GREEN....
|RW, PS
|RW to ask PS where he is on this; change ticket status to GREEN.
|
|}

===Actions for Torsten Schassan===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|

|TS
|TS to come up with a more detailed problem description and what the WG should attempt to solve by 2014-01-01.
|
|}

===Actions for Rebecca Welzenbach===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|[https://sourceforge.net/p/tei/feature-requests/384/ FR 384] : In April RW made a spreadsheet showing which elements she recommends moving into att.typed. And in...
|SB, RW
|SB and RW will review the list again.
|
|-
|Attributes without examples

|BB, RW
|BB and RW to turn into bug reports those attributes that are without examples that are high priority or need new/updated definitions.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/377/ FR 377] retaining punctuation marks in the text of a TEI document (AMBER open-accepted). RW says she has add...
|RW
|RW to finish the work and ask for help if necessary.
|
|-
|[https://sourceforge.net/p/tei/bugs/548/ BUG 548] use of modal verbs in Guidelines (AMBER pending-later). Already assigned to KH. RW agreed to help. I...
|KH, RW, LB
|KH and RW to create a new, detailed ticket with all questionable cases. In the meantime, LB will fix the edits that KH made at r12525.
|
|-
|[https://sourceforge.net/p/tei/bugs/558/ BUG 558] name/orgName (AMBER open). Action: RW to ask PS where he is on this; change ticket status to GREEN....
|RW, PS
|RW to ask PS where he is on this; change ticket status to GREEN.
|
|-
|[https://sourceforge.net/p/tei/bugs/401/ BUG 401] Most attributes lack good examples (GREEN open-accepted). This was previously discussed. Action: RW ...
|RW
|RW to follow up.
|
|}

[[Category:Council]]

Stand-off use cases

2012-05-11T01:19:55Z

Hcayless: /* Example from Papyri.info of personal name standoff markup */

[[category:markup]]

=== Use cases ===

This is a list of [http://en.wikipedia.org/wiki/Use_case use cases] for using stand-off markup in TEI. These examples are an attempt to build a shared common ground on which to move forward and are the (by-)product of a discussion on [http://listserv.brown.edu/?A0=TEi-SOM TEI-SOM]. Initials indicate discussion members who find this use case important or motivating.

# A third party publishes a text in non-TEI XML at a stable URL. You want to perform linguistic annotations on the text without losing reference to the underlying third party text. A TEI text is built with references back to the original non-TEI XML.
# A third party publishes a text in TEI at a stable URL. You want to perform linguistic annotations on the text without losing reference to the underlying third party text. A new TEI text is built with references back to the original TEI.
# A third party publishes a text in TEI XML at a stable URL. You want to perform linguistic annotations on the text without losing reference to the underlying third party text. A TEI text is built with references back to the original XML. (SY)
# There are multiple competing marking's up of linguistic information in a TEI text. The 'obvious' one is marked up and the others are relegated to stand-off markup. Tools are used to bring each alternative markup to the fore. (SY)
# There are multiple competing marking's up of linguistic information in a TEI text. Rather than privilege one marking up, all are relegated to stand-off markup. Tools are used to bring each alternative markup to the fore. (SY)
# A third party publishes a text in non-TEI XML at a stable URL. You wish to use TEI-based tools to find and correct errors in original XML and feed those corrections back to the publisher in a format native to them. (SY)
# Running an automated tool is run against an XML source, generating a TEI document which encodes information discovered in that source. For instance, you might run a process against an RSS news feed, and generate a TEI document containing analysis of it. You might store a copy of the feed with your TEI document, but you're not really interested in editing it; you're interested in what your process discovered about it (you might do sentiment analysis or something like that). Using TEI Pointers, you could point at target words or phrases in the RSS feed which form part of the analysis. [http://listserv.brown.edu/?A2=TEi-SOM;8464a70e.1205 from here] (MH)
# A text is being being published by the first the first time; TEI with stand-off markup is being used for the linguistic information. (SY)
# For the purpose of a training course, you want a group of students to do preliminary analysis of the same text (identifying salient features they would choose to mark up, delimiting structural blocks, etc.). An interface allows students to select points and ranges in the text, and attach annotations to them; these are stored in TEI as stand-off markup, and a rendering engine allows the group to view and discuss the annotations. Actual inline TEI can be generated from them when students are ready to begin their markup projects. (MH)
# Textual fragments from within a TEI text are extracted and used in an index into the text as part of the end-matter, in a manner akin to a back-of-the-book index. (see Papyri.info example below) (HC)

=== Challenging aspects of TEI texts ===

There are a number of challenging features sometimes found in TEI-encoding texts. These include:

# non-ASCII character sets (accents, macrons, Arabic, Far Eastern languages, etc)
# characters that do not qualify for inclusion in Unicode (see [http://www.nzetc.org/tm/scholarly/tei-Auc1911NgaM-t1-body-d4.html wh ligature], for exmaple)
# multicultural naming patterns (proper nouns in different language(s) or scripts to the underlying text, etc)
# texts with errors, omissions or additions
# texts which are compiled with other texts not of interest
# linguistically and etymologically complex features of interest: dates based on names ("In the eighth year of the reign of John"); places named after people ("Washington");
# existing semantic, linguistic, bibliographic or provenance tagging which needs to be integrated with the new taggings (usually the new taggings are linguistic in nature).

=== Example from Papyri.info of personal name standoff markup ===
(HC)

See [https://gist.github.com/2653676 O.Leid. 24]

The standoff annotation section starts at line 87. I'm doing the annotation in the same document for the sake of argument—it might not be the ultimate solution.

The use case is that I want to have an automated process attempt to recognize personal names in the text, and then provide an interface for users to correct the automated annotations. Because the text will be edited using a non-TEI interface that does not understand <persName> and the like, I cannot do this with inline markup. Inserting the name markup inline might be tough on the existing element hierarchy anyway. The data from the annotations will be submitted to a partner site, and we will keep the annotations as a record.

Note: I'm doing several things "wrong" here for the sake of argument. For starters, string-range() does not allow you to use a node without text in it as the first argument. I'd like to change that to allow the starting point to be, e.g. an <lb> (note, however, that if this were a sticking point, an XPath like //lb[@n='1']/following-sibling::text()[1] would work, it's just more verbose). Second, my use of string-range() is incorrect because it does not allow an XPath as the first argument. To be correct according to the current spec, I'd have to do something like:

<nowiki>#string-range(xpath1(//lb[@n='1']/following-sibling::text()[1]),3,6)</nowiki> instead of

<nowiki>#string-range(//lb[@n='1'],3,6)</nowiki>

Note too that since I'm keeping a copy of the recognized name, a scheme like match() might be a better fit, though again, I'd propose doing away with the restriction that the node pointed to must contain the text. In that case, I might posit something like:

<nowiki>#match(//lb[@n='1'],'Κράτης')</nowiki>

Stand-off use cases

2012-05-10T16:53:37Z

Hcayless:

[[category:markup]]
This is a list of [http://en.wikipedia.org/wiki/Use_case use cases] for using stand-off markup in TEI. These examples are an attempt to build a shared common ground on which to move forward and are the (by-)product of a discussion on [http://listserv.brown.edu/?A0=TEi-SOM TEI-SOM]. Initials indicate discussion members who find this use case important or motivating.

# A third party publishes a text in non-TEI XML at a stable URL. You want to perform linguistic annotations on the text without losing reference to the underlying third party text. A TEI text is built with references back to the original non-TEI XML.
# A third party publishes a text in TEI at a stable URL. You want to perform linguistic annotations on the text without losing reference to the underlying third party text. A new TEI text is built with references back to the original TEI.
# A third party publishes a text in TEI XML at a stable URL. You want to perform linguistic annotations on the text without losing reference to the underlying third party text. A TEI text is built with references back to the original XML. (SY)
# There are multiple competing marking's up of linguistic information in a TEI text. The 'obvious' one is marked up and the others are relegated to stand-off markup. Tools are used to bring each alternative markup to the fore. (SY)
# There are multiple competing marking's up of linguistic information in a TEI text. Rather than privilege one marking up, all are relegated to stand-off markup. Tools are used to bring each alternative markup to the fore. (SY)
# A third party publishes a text in non-TEI XML at a stable URL. You wish to use TEI-based tools to find and correct errors in original XML and feed those corrections back to the publisher in a format native to them. (SY)
# Running an automated tool is run against an XML source, generating a TEI document which encodes information discovered in that source. For instance, you might run a process against an RSS news feed, and generate a TEI document containing analysis of it. You might store a copy of the feed with your TEI document, but you're not really interested in editing it; you're interested in what your process discovered about it (you might do sentiment analysis or something like that). Using TEI Pointers, you could point at target words or phrases in the RSS feed which form part of the analysis. [http://listserv.brown.edu/?A2=TEi-SOM;8464a70e.1205 from here] (MH)
# A text is being being published by the first the first time; TEI with stand-off markup is being used for the linguistic information. (SY)
# For the purpose of a training course, you want a group of students to do preliminary analysis of the same text (identifying salient features they would choose to mark up, delimiting structural blocks, etc.). An interface allows students to select points and ranges in the text, and attach annotations to them; these are stored in TEI as stand-off markup, and a rendering engine allows the group to view and discuss the annotations. Actual inline TEI can be generated from them when students are ready to begin their markup projects. (MH)

== Example from Papyri.info of personal name standoff markup ==
(HC)

See [https://gist.github.com/2653676 O.Leid. 24]

The standoff annotation section starts at line 87.

The use case is that I want to have an automated process attempt to recognize personal names in the text, and then provide an interface for users to correct the automated annotations. Because the text will be edited using a non-TEI interface that does not understand <persName> and the like, I cannot do this with inline markup. Inserting the name markup inline might be tough on the existing element hierarchy anyway. The data from the annotations will be submitted to a partner site, and we will keep the annotations as a record.

Note: I'm doing several things "wrong" here for the sake of argument. For starters, string-range() does not allow you to use a node without text in it as the first argument. I'd like to change that to allow the starting point to be, e.g. an <lb> (note, however, that if this were a sticking point, an XPath like //lb[@n='1']/following-sibling::text()[1] would work, it's just more verbose). Second, my use of string-range() is incorrect because it does not allow an XPath as the first argument. To be correct according to the current spec, I'd have to do something like:

<nowiki>#string-range(xpath1(//lb[@n='1']/following-sibling::text()[1]),3,6)</nowiki> instead of

<nowiki>#string-range(//lb[@n='1'],3,6)</nowiki>

Note too that since I'm keeping a copy of the recognized name, a scheme like match() might be a better fit, though again, I'd propose doing away with the restriction that the node pointed to must contain the text. In that case, I might posit something like:

<nowiki>#match(//lb[@n='1'],'Κράτης')</nowiki>

Stand-off use cases

2012-05-10T16:53:20Z

Hcayless:

[[category:markup]]
This is a list of [http://en.wikipedia.org/wiki/Use_case use cases] for using stand-off markup in TEI. These examples are an attempt to build a shared common ground on which to move forward and are the (by-)product of a discussion on [http://listserv.brown.edu/?A0=TEi-SOM TEI-SOM]. Initials indicate discussion members who find this use case important or motivating.

# A third party publishes a text in non-TEI XML at a stable URL. You want to perform linguistic annotations on the text without losing reference to the underlying third party text. A TEI text is built with references back to the original non-TEI XML.
# A third party publishes a text in TEI at a stable URL. You want to perform linguistic annotations on the text without losing reference to the underlying third party text. A new TEI text is built with references back to the original TEI.
# A third party publishes a text in TEI XML at a stable URL. You want to perform linguistic annotations on the text without losing reference to the underlying third party text. A TEI text is built with references back to the original XML. (SY)
# There are multiple competing marking's up of linguistic information in a TEI text. The 'obvious' one is marked up and the others are relegated to stand-off markup. Tools are used to bring each alternative markup to the fore. (SY)
# There are multiple competing marking's up of linguistic information in a TEI text. Rather than privilege one marking up, all are relegated to stand-off markup. Tools are used to bring each alternative markup to the fore. (SY)
# A third party publishes a text in non-TEI XML at a stable URL. You wish to use TEI-based tools to find and correct errors in original XML and feed those corrections back to the publisher in a format native to them. (SY)
# Running an automated tool is run against an XML source, generating a TEI document which encodes information discovered in that source. For instance, you might run a process against an RSS news feed, and generate a TEI document containing analysis of it. You might store a copy of the feed with your TEI document, but you're not really interested in editing it; you're interested in what your process discovered about it (you might do sentiment analysis or something like that). Using TEI Pointers, you could point at target words or phrases in the RSS feed which form part of the analysis. [http://listserv.brown.edu/?A2=TEi-SOM;8464a70e.1205 from here] (MH)
# A text is being being published by the first the first time; TEI with stand-off markup is being used for the linguistic information. (SY)
# For the purpose of a training course, you want a group of students to do preliminary analysis of the same text (identifying salient features they would choose to mark up, delimiting structural blocks, etc.). An interface allows students to select points and ranges in the text, and attach annotations to them; these are stored in TEI as stand-off markup, and a rendering engine allows the group to view and discuss the annotations. Actual inline TEI can be generated from them when students are ready to begin their markup projects. (MH)

== Example from Papyri.info of personal name standoff markup ==
(HC)
See [https://gist.github.com/2653676 O.Leid. 24]

The standoff annotation section starts at line 87.

The use case is that I want to have an automated process attempt to recognize personal names in the text, and then provide an interface for users to correct the automated annotations. Because the text will be edited using a non-TEI interface that does not understand <persName> and the like, I cannot do this with inline markup. Inserting the name markup inline might be tough on the existing element hierarchy anyway. The data from the annotations will be submitted to a partner site, and we will keep the annotations as a record.

Note: I'm doing several things "wrong" here for the sake of argument. For starters, string-range() does not allow you to use a node without text in it as the first argument. I'd like to change that to allow the starting point to be, e.g. an <lb> (note, however, that if this were a sticking point, an XPath like //lb[@n='1']/following-sibling::text()[1] would work, it's just more verbose). Second, my use of string-range() is incorrect because it does not allow an XPath as the first argument. To be correct according to the current spec, I'd have to do something like:

<nowiki>#string-range(xpath1(//lb[@n='1']/following-sibling::text()[1]),3,6)</nowiki> instead of

<nowiki>#string-range(//lb[@n='1'],3,6)</nowiki>

Note too that since I'm keeping a copy of the recognized name, a scheme like match() might be a better fit, though again, I'd propose doing away with the restriction that the node pointed to must contain the text. In that case, I might posit something like:

<nowiki>#match(//lb[@n='1'],'Κράτης')</nowiki>