TEIWiki - User contributions [en]

Main Page

2023-05-08T18:59:21Z

James:

__NOTOC__ __NOEDITSECTION__

This is a wiki devoted to the '''[http://www.tei-c.org/ Text Encoding Initiative (TEI)]'''. It is created by TEI-ers for TEI-ers, and if you wish to contribute something or join the discussions, you are most welcome – all you need to do is [[Special:Userlogin| login or register]]. Choose from the following:

==== Technical matters: building and manipulating TEI XML ====
* [http://www.tei-c.org/Guidelines/P5/ TEI P5 '''Guidelines''']: [http://www.tei-c.org/Vault/P5/ current and archived past releases] in the [http://www.tei-c.org/Vault/ Vault]
** [http://www.tei-c.org/Support/Learn/tutorials.xml#tut-glp Project-specific encoding guidelines]
* Browse examples of markup or code submitted to this wiki:
** [[Samples|samples of TEI '''documents''']],
** [[:Category:Code|Code]]: [[:Category:XSLT|XSLT]], [[:Category:CSS|CSS]], [[:Category:XQuery|XQuery]], [[:Category:Schematron|Schematron]] and [[:Category:Code|more]].
* Read about [[:Category:Tools|useful '''software''' (editors, processors and such)]].
* Read about [[Roma]] and [[Vesta]], the software suites that produce TEI customizations, documentation and schemas, as well as [[ODD]], the language larger than TEI.
** [[:Category:Customization|customizations of TEI schemas (ODD files, DTD extensions)]],
* Find a [[Crosswalks|crosswalk]] (mapping) between a TEI header and another metadata format.
* See [[:Category:Projects|'''projects''' using TEI]] (in addition to [http://www.tei-c.org/Activities/Projects/ those listed on the TEI website]).
* [http://www.tei-c.org/Support/Learn/tutorials.xml#tut-gen XML, TEI by Example, What is the Text Encoding Initiative?, teiHeader '''tutorials''']

==== TEI Community matters ====
* [[TEI Cheatsheets]]
* [[:Category:Community|the TEI community and related communities]]
* [[FAQ]]
* [[Conferences]]
* [[Current events]]
* [[TEI-C_Board_of_Directors|Board of Directors]]
* [[Council|Technical Council]]
* [[:Category:SIG|Special Interest Groups (SIGs)]]: [[SIG:Computer-Mediated_Communication|Computer-Mediated Communication]], [[SIG:Correspondence|Correspondence]], [[SIG:Education|Education]], [[FacsimileMarkup|Facsimile Markup]], [[SIG:GraphTechnologies|Graph Technologies]] , [[SIG:IndicTexts|Indic Texts]], [[SIG:Libraries|Libraries]], [[SIG:MSS|Manuscripts]], [[SIG:Music|Music]], [[SIG:Newspapers&Periodicals|Newspapers and Periodicals]], [[SIG:Ontologies|Ontologies]], [[SIG:Overlap|Overlap]], [[SIG:Scholarly Publishing|Scholarly Publishing]], [[SIG:TEI_for_Linguists|TEI for Linguists]], [[SIG:Text&Graphic|Text and Graphics]], [[SIG:Tools|Tools]]
* [[:Category:Publications|Publication opportunities]]
* [[:Category:Grants|Grant opportunities]]
* [[:Category:Suggestions|Suggestions]]

==== TEI Wiki ====
* [[Help:Contents|Editing help]]
* [[TEIWiki:IdleTalk|<idleTalk/>]] – the local bulletin board
* [[Special:Wantedpages|Articles waiting to be born]]
* [[:Category:Articles that need extending|Articles that need extending]]
* [[Special:AllPages|All pages in the wiki]]
* [[Special:Categories|All categories in the wiki]]
* [[:Category:Users|Optional real TEIWiki-users list]]

See also the [http://www.tei-c.org/ main TEI web site] and the [https://github.com/TEIC/TEI TEI GitHub page]. The Text Encoding Initiative also has [http://en.wikipedia.org/wiki/Text_Encoding_Initiative an entry in Wikipedia].

----
'''Note:''' We require registration in order to avoid automated spam attacks and page vandalism. For the same reason, this front page has been locked and is unable to be edited by normal users. In addition, throughout the wiki certain key words which are prevalent in spam attacks have been banned. If you need to use any of these words, or to suggest a change to the homepage, please '''contact one of [[Special:ListUsers/sysop|the "bureaucrat" users]]'''.

Main Page

2023-05-08T18:53:01Z

James:

__NOTOC__ __NOEDITSECTION__

This is a wiki devoted to the '''[http://www.tei-c.org/ Text Encoding Initiative (TEI)]'''. It is created by TEI-ers for TEI-ers, and if you wish to contribute something or join the discussions, you are most welcome – all you need to do is [[Special:Userlogin| login or register]]. Choose from the following:

==== Technical matters: building and manipulating TEI XML ====
* [http://www.tei-c.org/Support/Learn/tutorials.xml#tut-gen XML, TEI by Example, What is the Text Encoding Initiative?, teiHeader '''tutorials''']
* [http://www.tei-c.org/Guidelines/P5/ TEI P5 '''Guidelines''']: [http://www.tei-c.org/Vault/P5/ current and archived past releases] in the [http://www.tei-c.org/Vault/ Vault]
** [http://www.tei-c.org/Support/Learn/tutorials.xml#tut-glp Project-specific encoding guidelines]
* Browse examples of markup or code submitted to this wiki:
** [[Samples|samples of TEI '''documents''']],
** [[:Category:Code|Code]]: [[:Category:XSLT|XSLT]], [[:Category:CSS|CSS]], [[:Category:XQuery|XQuery]], [[:Category:Schematron|Schematron]] and [[:Category:Code|more]].
* Read about [[:Category:Tools|useful '''software''' (editors, processors and such)]].
* Read about [[Roma]] and [[Vesta]], the software suites that produce TEI customizations, documentation and schemas, as well as [[ODD]], the language larger than TEI.
** [[:Category:Customization|customizations of TEI schemas (ODD files, DTD extensions)]],
* Find a [[Crosswalks|crosswalk]] (mapping) between a TEI header and another metadata format.
* See [[:Category:Projects|'''projects''' using TEI]] (in addition to [http://www.tei-c.org/Activities/Projects/ those listed on the TEI website]).

==== TEI Community matters ====
* [[TEI Cheatsheets]]
* [[:Category:Community|the TEI community and related communities]]
* [[FAQ]]
* [[Conferences]]
* [[Current events]]
* [[TEI-C_Board_of_Directors|Board of Directors]]
* [[Council|Technical Council]]
* [[:Category:SIG|Special Interest Groups (SIGs)]]: [[SIG:Computer-Mediated_Communication|Computer-Mediated Communication]], [[SIG:Correspondence|Correspondence]], [[SIG:Education|Education]], [[FacsimileMarkup|Facsimile Markup]], [[SIG:GraphTechnologies|Graph Technologies]] , [[SIG:IndicTexts|Indic Texts]], [[SIG:Libraries|Libraries]], [[SIG:MSS|Manuscripts]], [[SIG:Music|Music]], [[SIG:Newspapers&Periodicals|Newspapers and Periodicals]], [[SIG:Ontologies|Ontologies]], [[SIG:Overlap|Overlap]], [[SIG:Scholarly Publishing|Scholarly Publishing]], [[SIG:TEI_for_Linguists|TEI for Linguists]], [[SIG:Text&Graphic|Text and Graphics]], [[SIG:Tools|Tools]]
* [[:Category:Publications|Publication opportunities]]
* [[:Category:Grants|Grant opportunities]]
* [[:Category:Suggestions|Suggestions]]

==== TEI Wiki ====
* [[Help:Contents|Editing help]]
* [[TEIWiki:IdleTalk|<idleTalk/>]] – the local bulletin board
* [[Special:Wantedpages|Articles waiting to be born]]
* [[:Category:Articles that need extending|Articles that need extending]]
* [[Special:AllPages|All pages in the wiki]]
* [[Special:Categories|All categories in the wiki]]
* [[:Category:Users|Optional real TEIWiki-users list]]

See also the [http://www.tei-c.org/ main TEI web site] and the [https://github.com/TEIC/TEI TEI GitHub page]. The Text Encoding Initiative also has [http://en.wikipedia.org/wiki/Text_Encoding_Initiative an entry in Wikipedia].

----
'''Note:''' We require registration in order to avoid automated spam attacks and page vandalism. For the same reason, this front page has been locked and is unable to be edited by normal users. In addition, throughout the wiki certain key words which are prevalent in spam attacks have been banned. If you need to use any of these words, or to suggest a change to the homepage, please '''contact one of [[Special:ListUsers/sysop|the "bureaucrat" users]]'''.

Talk:Main Page

2023-05-08T18:42:24Z

James: /* Registration */ new section

== Banned strings ==

It says certain words have been banned because they're commonly used in spam but to "let us know" if you want to use any of them. Who should we contact?
:Hi Kevin -- I know the pain, I once wanted to use the word 'specialist' and couldn't save (note the 'cialis' substring). Note also that I circumvented the filter (see the source). Which is not exactly a strong argument against using the filter, but it is ''some'' kind of argument for sure. So until you reach James and perhaps James reaches Chris (not sure if he needs to in this respect) in order to whitelist the relevant words, this may be the way to proceed. (Hmm, should I keep this secret from "the public"? But our public is not really prone to that sort of mischief, so I don't think I'm risking much ;-)) [[User:Piotr Banski|Piotr]] 17:52, 7 November 2010 (EST)
:: How can we do in order to change filters behaviour? I tried to give examples in the CMC SIG of participants' description. I cannot even use the TEI element corresponding to gender, which TEI decided to give another name I cannot pronounced here (chut :-) ) because the filter removed all my examples. How strange! Can it be adjusted? Thanks in advance.--[[User:Thierry CHANIER|Thierry CHANIER]] 15:06, 8 April 2014 (CEST)
::: Dear Thierry, please see the source of this section for one way to avoid the filter. Basically, you want to disrupt the contiguity of the "offending" strings. Best, [[User:Piotr Banski|Piotr]] 15:17, 8 April 2014 (CEST)

== More links on home page ==

I suggest adding links to http://wiki.tei-c.org/index.php/Special:AllPages and http://wiki.tei-c.org/index.php/Special:Categories to the Wiki home page.

There is much more in the Wiki than I realized before finding these two pages.

: Done ([[User:Kshawkin|Kshawkin]] 09:58, 4 August 2012 (EDT))

== Registration ==

There is a link to 'login or register' which just allows one to login not register. I believe this is controlled in the settings somewhere and the registrations are turned off. What we should do is turn it back on but then require any new registrations to be approved.

-[[User:James|JamesC]] ([[User talk:James|talk]])

Roma

2023-05-08T18:40:21Z

James: Minor Change: Warning that this is all about Roma Antiqua https://romaantiqua.tei-c.org/

= WARNING =
This wiki page refers to the old version of Roma: https://romaantiqua.tei-c.org/

== Synopsis ==

'''Roma''' is the web based TEI software for generating customisations from [http://www.tei-c.org/P5/ P5] [[ODD]] specifications. It was written by Arno Mittelbach and is loosely maintained by the TEI Council.

Roma's basic job is to construct an XML document, the TEI "ODD". To generate output (RELAXNG schemas, W3C schemas, HTML documentation, etc.), Roma relies on the [[OxGarage]] web service to provide the necessary transformations.

Historically, there has been a Roma CLI tool, but this is superseded by the appropriate ANT or Shell scripts provided by the [[Tei-xsl|TEI Stylesheets]] themselves.

== Features ==

== User commentary ==
'''Please sign all comments.'''

== System requirements ==
A standard modern web browser is all that is required to make use of the Roma Web Client. If you want to deploy the underlying system yourself the most convenient way is via [https://www.docker.com Docker] which is available for most platforms.

== Source code and licensing ==
Roma source code is hosted on Github, at https://github.com/TEIC/roma

== Support for TEI ==

== Language(s) ==

== Documentation ==
For the web version, see [http://www.tei-c.org/Guidelines/Customization/use_roma.xml Customizing the TEI with Roma].

For instructions on installing the command-line version under Mac OS X, see [http://www.wwp.northeastern.edu/outreach/seminars/_current/handouts/roma_CLI_MacOS_X.html Roma CLI Instructions] [note that the locations of stylesheet and roma have moved to github and the links given are out of date, cf. [http://lists.village.virginia.edu/pipermail/tei-council/2013/018680.html]].

As Sebastian wrote on TEI-L on 2009-12-21, "Always remember when considering Roma and friends that the variation is in the XSL stylesheets which it uses. So 99% of error reports and bug fixes are to do with the behaviour of odd2odd.xsl and odd2relax.xsl (etc). The XSL package changes much more frequently than Roma."

== Tech support ==
Report problems either at the [[TEI-L]] list or in the [https://github.com/TEIC/Roma/issues GitHub issue tracker].

== User community ==

== Sample implementations ==
* Production version: http://roma.tei-c.org/ (running on the main TEI server)
* Development version: https://roma2.tei-c.org (currently running at Paderborn University)

== Current version number and date of release ==
* 5.0.0 (2018-07-18)

== History of versions ==

=== GitHub releases ===

https://github.com/TEIC/Roma/releases

=== old releases on SourceForge ===

https://sourceforge.net/projects/tei/files/Roma/

== How to download or buy ==

There are two options.

=== a) Pull from Docker (recommended) ===

docker pull teic/roma

=== b) Download/Clone from GitHub (for developers) ===

see https://github.com/TEIC/Roma

== Getting the Roma server running ==

The recommended way is to run Roma via Docker. Detailed instructions can be found in the [https://github.com/TEIC/Roma/blob/dev/README.md project Readme].

== Additional notes ==
Also see [[OxGarage]] and [[Vesta]].

[[Category:Tools]]

FAQ-Developers

2019-09-15T15:46:53Z

James: Page initial draft

This page is intended to collect FAQs about the TEI specifically for those writing software, building websites, or transforming TEI in any vague sense.



; How can I programmatically determine if the version of the released TEI has changed since the last time I ran the software? : Compare your stored version number with the contents of https://www.tei-c.org/Vault/P5/current/doc/tei-p5-doc/VERSION which should contain the version number of the current released version.

User:James

2019-08-30T13:27:31Z

James: Wow, that was really out of date.

'''Dr James Cummings''' 
Senior Lecturer in Late Medieval Literature and Digital Humanities 
Newcastle University

[[Category:Users|James]]

Samples of TEI texts

2019-05-21T07:28:52Z

James: Really just a test edit.

[[Category: Markup]] [[Category: TEI:P4]] [[Category: TEI:P5]] __NOTOC__
The availability of texts enables others to learn by example; it fosters similar approaches to solving the same problems across the entire community of practice; and it gives developers of TEI-based tools a broader sample of texts to test against. The fact a text is listed here should not be taken as a licence to redistribute the text, please check with text owners should they wish to make any more in-depth use of these materials.

== Explicitly Pedagogical Samples ==

* [http://teibyexample.org TEI By Example] is a set of examples design to teach the basics of TEI. Includes TEI P3 (SGML) and P5 examples. [http://creativecommons.org/licenses/by-sa/3.0/ CC licensed].

== Texts ==

* [http://insaph.kcl.ac.uk/ala2004/redist/inscriptions/inscriptions.zip ala2004] ([[EpiDoc]] XML) from the [http://insaph.kcl.ac.uk/ala2004 '''Aphrodisias in Late Antiquity'''] publication. The downloadable .zip archive contains 230 XML files, each containing an ancient Greek inscription, which validate to the version 4 of the [http://epidoc.sf.net/ EpiDoc] DTD (a TEI localization)--the DTD is also included in the archive. These files are licenced under [http://creativecommons.org/licenses/by/2.5/ Creative Commons Attribution], so please feel free to do whatever you like with them! (Format: TEI P4)

* [http://archimedespalimpsest.net/ '''Archimedes Palimpsest'''], XML files containing the transcriptions of the Archimedes text, released (like all the Palimpsest data and metadata) under Creative Commons Attribution 3.0 Unported. Texts validate to TEI P5. One XML file per folio page (scroll down list of hi-res photographs in each directory). Format: TEI P5

* [https://github.com/StanfordUniversityLibraries/ap_tei '''FRDA'''] (French Revolution Digital Archive) TEI of full text for 82 volumes of French Revolution parliamentary debates from 1787 to 1794

* [http://www.ota.ox.ac.uk/headers/2493.xml The '''Auchinleck Manuscript'''], made available by the [http://www.ota.ox.ac.uk/ Oxford Text Archive] contact [mailto:ota-info@rt.oucs.ox.ac.uk ota-info@rt.oucs.ox.ac.uk]. This text originates from the [http://www.nls.uk/auchinleck/ Auchinleck Manuscript Project] at the National Library of Scotland, please see their website for more contextual material. Format: TEI P5.

* [https://github.com/CopticScriptorium/corpora Coptic SCRIPTORIUM corpora] for the [http://copticscriptorium.org/ Coptic SCRIPTORIUM]

* [http://www.deutschestextarchiv.de/download '''DTA'''] Deutsches Textarchiv (2435 texts as of 2016-12-21)

* [http://dramacode.github.io Dramacode], French classical plays (Corneille, Molière, Racine, etc.)

* [https://github.com/textcreationpartnership '''EEBO'''] collection Phase 1 TEI P5 XML versions of texts (Text Creation Partnership's Early English Books Online) ([https://raw.githubusercontent.com/textcreationpartnership/Texts/master/TCP.csv CSV file listing all the texts]) (32853 texts as of 2015-01-01)

* [https://github.com/papyri/idp.data '''Duke Databank'''/Heidelberg/APIS] ([[EpiDoc]] XML) aggregated data from the Duke Databank of Documentary Papyri (DDbDP: transcribed Greek texts) the Heidelberger Gesamtverzeichnis der griechischen Papyrusurkunden Ägyptens (HGV: metadata), and the Advanced Papyrological Information System. Approx 145,000 XML files released under Creative Commons Attribution license (CC-BY), by the [http://idp.atlantides.org/trac/idp/wiki Integrating Digital Papyrology] project. Format: TEI P5.

* [http://epidoc.cch.kcl.ac.uk/inscriptions/index.html '''EpiDoc Demo''' Website], a growing collection of sample [[EpiDoc]] XML files, including examples from epigraphic, papyrological, and other ancient projects. XML downloadable from each transformed inscription. (Vintage 2007.) (Format: TEI P4)

* [http://www.folgerdigitaltexts.org/ '''Folger Digital Texts''']: From the Folger Shakespeare Library, "Each play in Folger Digital Texts is rigorously encoded: every word, every punctuation mark, every space, within a sophisticated, TEI-compliant XML structure."

* A subset of [http://www.gutenberg.org/ Project '''Gutenberg'''] is available as TEI, go to [http://www.gutenberg.org/catalog/world/search http://www.gutenberg.org/catalog/world/search] and select "TEI Text Encoding Initiative (tei)" as the file type.

* [http://insaph.kcl.ac.uk/iaph2007/inscriptions/xml-repo.html '''IAph2007''' ([[EpiDoc]] XML files)] from the [http://insaph.kcl.ac.uk/iaph2007/ Inscriptions of Aphrodisias (2007)] publication. There are approx 1500 XML files available (either in a single .zip or as individual files either downloadable or linkable directly for dynamic processing), each containing an ancient Greek or Latin inscription. All files validate to the [[EpiDoc]] DTD (version 5). These files are licensed under [http://creativecommons.org/licenses/by/2.0/uk/ Creative Commons Attribution (UK)], so please feel free to do exciting things with them. (Format: TEI P4)

* [http://irt.kcl.ac.uk/irt2009/inscr/xmlrepo.html '''Inscriptions of Roman Tripolitania''' 2009] ([[EpiDoc]] XML), about 1000 Latin and Greek inscriptions available for download under Creative Commons Attribution (CC-BY) licence. Format: TEI P4.

* [http://www.sbl-site.org/Resources/Resources_ManuscriptMarkup.aspx Files] referenced in Timothy J. Finney, "'''Manuscript Markup'''," in ''The Freer Biblical Manuscripts: Fresh Studies of an American Treasure Trove'' (ed. Larry W. Hurtado; SBLTCS 6; Atlanta: Society of Biblical Literature, 2006), 263-87. These include a partial [http://www.sbl-site.org/assets/U16/U16.xml transcription] of the Freer manuscript of Paul (Gregory-Aland I 016), a [http://www.sbl-site.org/assets/U16/U16.xsl transform], a [http://www.sbl-site.org/assets/U16/U16.css stylesheet] and a [http://www.sbl-site.org/assets/U16/U16.htm web page] produced from the transcription by the transform. (Format: TEI P5)

* The [http://www.nzetc.org/ NZETC] has a range of '''New Zealand and Pacific-Islands''' texts. The texts are P5 encoded and the TEI is generally downloadable from the document table of contents. Features include:
** Use of <revisionDesc> and <change> tags to implement workflow
** <name> tag used extensively for personal, ship, place, organisation and work names (keyed to external authority at [http://authority.nzetc.org/])
** Use of xml:lang="en" and xml:lang="mi" for texts with English and Maori (plus small amounts of other languages)
** Page images, facsimile PDFs and typeset PDFs (some texts only, for example [http://www.nzetc.org/tm/scholarly/tei-JCB-001.html this letter])
** Document-by-document licensing, some documents under a creative commons license (licensing info not currently stored in the TEI).

* The University of [http://www.ota.ox.ac.uk/ '''Oxford Text Archive'''] (OTA) is home to some 2685 TEI P5 texts, including all of the ECCO texts which are in the public domain, all available under CC licences, plus some TEI P5 linguistic corpora, and others following older editions of the guidelines, with legacy licences. The OTA exists as a community resource, and projects and people are encouraged to offer texts for deposit in the archive.

* The [http://www.perseus.tufts.edu/hopper/opensource Perseus Project] makes its TEI P4 XML collections in Greek, Latin, and English available from http://www.perseus.tufts.edu/hopper/opensource under a Creative Commons Sharalike/Non-Commercial/Attribution license.

* The [http://buddhistinformatics.ddbc.edu.tw/BZA/bzaComCatWeb.html '''Samyukta Agama''' Project] at Dharma Drum Buddhist College provides access to its more than 1000 TEI source files. Click on any cluster and find the link to the TEI source at the bottom of each column. The files are in Chinese, Pali and Sanskrit. Markup documentation, schemas and stylesheets are available as a zip archive at the website.

* The [http://buddhistinformatics.ddbc.edu.tw/biographies/gis/ '''Chinese Buddhist Bibliographies''' Project] at Dharma Drum Buddhist College provides access to different collections with more than 1000 biographies marked up in TEI for place and person names as well as dates. The archives contain basic documentation, schema etc. The data is in Chinese, linked to authority databases and available through three different interfaces visualizing it as GIS light, social network and on a timeline. All the data is published under a CC licence.

* The [http://buddhistinformatics.ddbc.edu.tw/fosizhi/ '''Chinese Buddhist Temple Gazetteers''' Project] at Dharma Drum Buddhist College provides access to topographical descriptions of Buddhist temple marked up for place and person names as well as dates. All together there are 237 gazetteers, 13 of which are available with TEI markup and new punctuation. The archives contain the TEI, image files referenced in the TEI, schema, METS wrapper etc. The data is linked to authority databases and available through an interface that displays the marked-up edition next to the images. The data is published under a CC licence.

* The [http://www.tei-c.org/Activities/MI/Samples/ '''Migration Samples'''] page on the main TEI website includes sample texts from (inter alia) the British National Corpus, the Thomas McGreevey Archive, Early English Books Online, Multext East, Documenting the American South, and the Women Writers Project which were prepared as part of the TEI P4 Migration Work Group, the purpose of which was to demonstrate how to migrate TEI P3 (SGML) to TEI P4 (XML). Most of the material here is therefore of a certain antiquity.

* The [http://www.bvh.univ-tours.fr/ BVH] project ('''Virtual Humanistic Libraries''') is a virtual library of high-quality digitised documents, offering a selection of Renaissance books located in the libraries of the Région Centre, Paris, Poitiers, Lyons, Troyes, etc. Three samples of TEI texts are proposed in html, pdf and xml/tei on [http://www.bvh.univ-tours.fr:8080/xtf/search?title=&creator=&year=&keyword=&type=tei Epistemon]. These files are licenced under Creative Commons Attribution.

* [https://github.com/iulibdcs/tei_text TEI and Plain Text from Digital Collections Services, Indiana University Libraries]

* TEI in dspace example http://dspace.nitle.org/handle/10090/11695 (P4?) (seems broken May 2012)

* The [http://sarit.indology.info SARIT] project has recently brought out an electronic TEI-encoded edition of a 2007 print publication. It is a work on Buddhist tantric religion: Christian K. Wedemeyer, ed., ''Āryadeva's Lamp that Integrates the Practices (Caryāmelāpakapradīpa): The Gradual Path of Vajrayāna Buddhism According to the Esoteric Community Noble Tradition - Part Three: Critically Edited Sanskrit Text of Āryadeva's Caryāmelāpakapradīpa,'' (New York: The American Institute of Buddhist Studies at Columbia University in New York with Columbia University's Center for Buddhist Studies and Tibet House US, 2007). E-details and full text can be seen [[http://sarit.indology.info/newphilo/navigate.pl?indologica.16 here]]. Clicking [[http://sarit.indology.info/downloads.shtml Downloads]] on the above screen offers downloadable TEI, PDF and HTML versions of this e-text, and several others. The interesting thing about this e-text from the TEI point of view is the encoding and display of the manuscript variants to the critical edition. It was good of the publishers and editors to give their permission for the e-dissemination of this work just three years after print publication. Best, Dr Dominik Wujastyk.

* [http://txm.bfm-corpus.org/?command=documentation&path=/GRAAL '''La Queste del Saint Graal'''] (The Quest of the Holy Grail) online interactive edition offers a parallel multi-level (normalized, diplomatic and imitative) transcription of the Lyon MN PA 77 manuscript along with manuscript images and a translation in modern French, powered by TXM text search and statistical analysis platform. The complete source XML-TEI P5 encoded with Menota extensions manuscript transcriptions and an ODD customization file, as well as the stylesheets used to produce HTML editions and a PDF printable version are freely available for [http://txm.bfm-corpus.org/txm/images/graal_src.zip download] under a CC BY-NC-SA 3.0 license.

* [http://docsouth.unc.edu/southlit/poe/menu.html "Tales" by Edgar Allan Poe] at University of North Carolina at Chapel Hill. Uses mnemonic entity references for non-ASCII characters.

* [https://github.com/TEI-examples/tei-examples tei-examples] -- Examples of TEI documents dealing with different use-cases.

* [https://textgrid.de/digitale-bibliothek '''TextGrid''' Digital Library] conversion from Zeno-XML-Markup to XML-TEI and additional markup

* [https://github.com/stuartyeates/sampler URLs to diverse TEI files] in terms of language, structure, linguistics, coding, tools in use, hosting method, etc.

* [http://vangoghletters.org/vg/ Vincent Van Gogh: The Letters] -- See [http://vangoghletters.org/vg/about_6.html "About this edition"].

* [https://github.com/oeuvres Works in French and TEI] (Baudelaire, Hugo, Rimbaud, Verlaine, Balzac, Descartes, La Fayette, Sade, Saint-Simon, etc.)

== Dictionaries ==
* [[FreeDict]] is a repository of various TEI-encoded bilingual translating dictionaries on free licenses (http://www.freedict.org/). Most of the dictionaries have been converted from TEI P4 to TEI P5, but not all of the changes can be found in the official releases yet. Visiting [http://freedict.svn.sourceforge.net/viewvc/freedict/trunk/ the SVN repository] directly may be the better way out.
* [http://ducange.enc.sorbonne.fr/ Du Cange] is a medieval latin dictionary (mostly written during XVIIe XVIIIe). The printed text is encoded in TEI-P5, freely available at http://svn.code.sf.net/p/ducange/code/xml/ as an [http://sourceforge.net/p/ducange/wiki/Home/ open source project]. The TEI choices are [http://svn.code.sf.net/p/ducange/code/xml/ducange.html documented (in french)].
* [http://algone.net/littre/ Littré] a classical French dictionary, encoded in TEI-P5, freely available at https://svn.code.sf.net/p/javacrim/code/littre/xml/, [https://svn.code.sf.net/p/javacrim/code/littre/xml/schema.html documented in French with the words of Littré himself]

TEI-Council-FAQ

2017-12-08T17:52:25Z

James: /* TEI Technical Council Chair */

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: http://www.tei-c.org/Admin/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 SourceForge ==

=== 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 Sourceforge Subversion Repositories, with read access to anyone who wishes. See the [http://www.tei-c.org/Guidelines/P5/get.xml instructions]. Write access is reserved for those who are developers on the SourceForge project. To request developer status, contact one of the project admins, whose usernames are given in bold on [http://sourceforge.net/project/memberlist.php?group_id=106328 the SourceForge list of users].

Note that you will have to enter your password each time you access Subversion. A way around this (which causes a security risk) is to create a public/private key pair based on no passphrase and upload your public key to SF. There is a [http://www.linuxproblem.org/art_9.html description of how this process works in general], and [https://sourceforge.net/p/forge/documentation/SSH%20Keys/ some hard-to-follow instructions specific to SourceForge].

=== 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:
* 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]]

Rahtz Prize for TEI Ingenuity

2016-09-12T14:25:56Z

James: added bit of bio and link to wikipedia page.

==About the Rahtz Prize==

In memory and honor of [https://en.wikipedia.org/wiki/Sebastian_Rahtz Sebastian Rahtz] (13 February 1955 – 15 March 2016), the TEI Consortium has created the Rahtz Prize for TEI Ingenuity, an award
that is intended to capture’s Sebastian’s spirit and marked technical and philosophical contributions to the TEI, and encourage TEI innovation by the TEI community.

Sebastian was responsible for the design and implementation of a great deal of the TEI's technical infrastructure. Inside the TEI community he was most well-known for the creation and maintenance of the XSLT Stylesheets that underlie much TEI conversion work and schema generation. As a member of the TEI Technical Council he contributed to all aspects but especially working on improvements to the processing of TEI ODD customisations.

The Rahtz Prize for TEI Ingenuity is awarded annually to an individual or team for a significant contribution in advancing the [http://www.tei-c.org/About/mission.xml TEI-C's mission] with respect to technical innovation. Many of us are often exploring or implementing ways to expand the TEI, and we hope this Prize will recognize the great work that is already being done or incentivize the work that is meaning to be done.

==Important Info and Dates ==

* $1,000 USD will be awarded to one individual or team per year
* 1 August: Submissions Due
* 15 September: Winner Selected
* Annual Business Meeting: Winner Announced

==Submission Rules and Guidelines==

Applications for the Rahtz Prize for TEI Ingenuity may be [https://goo.gl/forms/ZX4NKQ3cPHnBvSxK2 submitted online] ([https://goo.gl/forms/ZX4NKQ3cPHnBvSxK2 https://goo.gl/forms/ZX4NKQ3cPHnBvSxK2]) at any time but must be submitted by midnight in Hawaii on 1 August in order to be considered for awarding at that year's TEI members' meeting.

Along with contact information, applicants will be asked to submit a 500-1,500 summary describing the project/initiative. This summary should reflect the [http://www.tei-c.org/About/mission.xml TEI-C's mission] and the criteria as outlined below.

===Eligibility===
* Individuals or teams are eligible to apply. Membership to the TEI-Consortium is not a requirement.
* If awarded, the individuals/teams are eligible to submit another application three (3) years after the granted award.

==Review Process and Criteria==

The submissions will be reviewed by a panel of three judges: the Chair of the TEI-C Board of Directors, the Chair of the TEI-C Technical Council, and an invited, long-time and active member from the TEI Community. A new panel of judges may change as frequently as every year, but the same jury member should not serve more than 3 consecutive years. The Community judge will be identified and agreed upon jointly by the Board and the Council by 1 July.

Contributions should reflect:

* innovative development of the TEI-C Guidelines
* the creation of TEI-aware tools and technologies that further dissemination, adoption, and engaged use of the TEI-C Guidelines
* expansive and inclusive training and outreach opportunities
* the cultivation of particular TEI-C researcher and practitioner communities

==Terms==
The recipient(s) will receive a cash award of $1,000 USD, or a round number of about the same value in the currency in which the prize is to be awarded. The final selection is made by the panel of judges and announced as part of the Business Meeting, which occurs as part of the annual TEI-C Conference and Members' Meeting. The disbursement of the cash award is arranged through the TEI-C Treasurer.

[[Category:Board]]

Digital Medievalist Project

2016-04-05T16:28:41Z

James: they no longer have a wiki

The [http://www.digitalmedievalist.org/ Digital Medievalist Project] is an on-line [[Wikipedia:Community_of_practice|community of practice]] that focusses on the use of technology in the study of medieval language, culture, and history. The project also runs a [[DigitalMedievalist|peer-reviewed journal]] devoted to the documentation of best practice in the use of electronic media for this field.

[[Category:Projects]]

TEI-Council-FAQ

2015-11-16T15:30:58Z

James: /* TEI Technical Council Chair */

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
* budgeting Council expenses,
* 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 unsworth AT brandeis.edu.

Use the TEI Travel expense form available here: http://www.tei-c.org/Admin/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 SourceForge ==

=== 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 Sourceforge Subversion Repositories, with read access to anyone who wishes. See the [http://www.tei-c.org/Guidelines/P5/get.xml instructions]. Write access is reserved for those who are developers on the SourceForge project. To request developer status, contact one of the project admins, whose usernames are given in bold on [http://sourceforge.net/project/memberlist.php?group_id=106328 the SourceForge list of users].

Note that you will have to enter your password each time you access Subversion. A way around this (which causes a security risk) is to create a public/private key pair based on no passphrase and upload your public key to SF. There is a [http://www.linuxproblem.org/art_9.html description of how this process works in general], and [https://sourceforge.net/p/forge/documentation/SSH%20Keys/ some hard-to-follow instructions specific to SourceForge].

=== 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:
* 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

2015-11-16T15:14:55Z

James: noting some places changes need to be made.

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://tei.sourceforge.net/ the SourceForge system]
* acting as SIG coordinator
* liaising for and reporting on Council activities at all Board meetings
* reflecting Council wishes in Board discussions
* budgeting Council expenses,
* 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 unsworth AT brandeis.edu.

Use the TEI Travel expense form available here: http://www.tei-c.org/Admin/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 SourceForge ==

=== 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 Sourceforge Subversion Repositories, with read access to anyone who wishes. See the [http://www.tei-c.org/Guidelines/P5/get.xml instructions]. Write access is reserved for those who are developers on the SourceForge project. To request developer status, contact one of the project admins, whose usernames are given in bold on [http://sourceforge.net/project/memberlist.php?group_id=106328 the SourceForge list of users].

Note that you will have to enter your password each time you access Subversion. A way around this (which causes a security risk) is to create a public/private key pair based on no passphrase and upload your public key to SF. There is a [http://www.linuxproblem.org/art_9.html description of how this process works in general], and [https://sourceforge.net/p/forge/documentation/SSH%20Keys/ some hard-to-follow instructions specific to SourceForge].

=== 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:
* 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]]

DH2015-Hackathon

2015-03-23T18:52:52Z

James: Created page with " This is a holding page for more information concerning the TEI HackAThon at DH2015. More details to be posted soon."

This is a holding page for more information concerning the TEI HackAThon at DH2015.

More details to be posted soon.

TEI-Council-FAQ

2015-02-24T10:51:02Z

James: /* Why do some elements have @type and others do not? */

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 in [http://tei.sourceforge.net/ SourceForge].
# 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 SourceForge Subversion). If it is not a real issue, sometimes the ticket will just be closed. If you do not have developer access on sourceforge you'll need to ask someone who does to re-open the ticket if you want to raise it again. 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 SourceForge 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 SourceForge 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 David Sewell (Virginia) and Kevin Hawkins (North Texas). 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 other systems administrators 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 [http://tei.sourceforge.net/ the TEI's SourceForge 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://tei.sourceforge.net/ the SourceForge system]
* acting as SIG coordinator
* liaising for and reporting on Council activities at all Board meetings
* reflecting Council wishes in Board discussions
* budgeting Council expenses,
* 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.

=== 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 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 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 <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 unsworth AT brandeis.edu.

Use the TEI Travel expense form available here: http://www.tei-c.org/Admin/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? ===

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 SourceForge 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 SourceForge 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 sourceforge. 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? ===

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 SourceForge? ===
All members of Council are made 'developers' on the SourceForge TEI Project 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 Subversion 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 SourceForge ==

=== 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_Subversion.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 subversion repository? ===

# Go to https://lists.sourceforge.net/lists/listinfo/tei-notify .
# Subscribe under your SourceForge email address (which you can find at http://sourceforge.net/project/memberlist.php?group_id=106328 ).

=== How do I use Subversion? ===

The TEI stores its working files in the TEI Sourceforge Subversion Repositories, with read access to anyone who wishes. See the [http://www.tei-c.org/Guidelines/P5/get.xml instructions]. Write access is reserved for those who are developers on the SourceForge project. To request developer status, contact one of the project admins, whose usernames are given in bold on [http://sourceforge.net/project/memberlist.php?group_id=106328 the SourceForge list of users].

Note that you will have to enter your password each time you access Subversion. A way around this (which causes a security risk) is to create a public/private key pair based on no passphrase and upload your public key to SF. There is a [http://www.linuxproblem.org/art_9.html description of how this process works in general], and [https://sourceforge.net/p/forge/documentation/SSH%20Keys/ some hard-to-follow instructions specific to SourceForge].

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

It is beneficial to all those looking at the TEI Subversion 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:
* an explanation to a useful level of detail about what you did
* a mention of why this is being done
* the SourceForge ticket numbers (or shortened 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 webmaster(s) -- currently David Sewell, with assistance from Kevin Hawkins -- 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

2015-02-24T10:46:02Z

James: /* 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 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 in [http://tei.sourceforge.net/ SourceForge].
# 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 SourceForge Subversion). If it is not a real issue, sometimes the ticket will just be closed. If you do not have developer access on sourceforge you'll need to ask someone who does to re-open the ticket if you want to raise it again. 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 SourceForge 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 SourceForge 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 David Sewell (Virginia) and Kevin Hawkins (North Texas). 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 other systems administrators 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 [http://tei.sourceforge.net/ the TEI's SourceForge 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://tei.sourceforge.net/ the SourceForge system]
* acting as SIG coordinator
* liaising for and reporting on Council activities at all Board meetings
* reflecting Council wishes in Board discussions
* budgeting Council expenses,
* 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.

=== 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 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 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 <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 unsworth AT brandeis.edu.

Use the TEI Travel expense form available here: http://www.tei-c.org/Admin/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? ===

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 SourceForge 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 SourceForge 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 sourceforge. 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? ===

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 SourceForge? ===
All members of Council are made 'developers' on the SourceForge TEI Project 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 Subversion 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 SourceForge ==

=== 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_Subversion.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 subversion repository? ===

# Go to https://lists.sourceforge.net/lists/listinfo/tei-notify .
# Subscribe under your SourceForge email address (which you can find at http://sourceforge.net/project/memberlist.php?group_id=106328 ).

=== How do I use Subversion? ===

The TEI stores its working files in the TEI Sourceforge Subversion Repositories, with read access to anyone who wishes. See the [http://www.tei-c.org/Guidelines/P5/get.xml instructions]. Write access is reserved for those who are developers on the SourceForge project. To request developer status, contact one of the project admins, whose usernames are given in bold on [http://sourceforge.net/project/memberlist.php?group_id=106328 the SourceForge list of users].

Note that you will have to enter your password each time you access Subversion. A way around this (which causes a security risk) is to create a public/private key pair based on no passphrase and upload your public key to SF. There is a [http://www.linuxproblem.org/art_9.html description of how this process works in general], and [https://sourceforge.net/p/forge/documentation/SSH%20Keys/ some hard-to-follow instructions specific to SourceForge].

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

It is beneficial to all those looking at the TEI Subversion 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:
* an explanation to a useful level of detail about what you did
* a mention of why this is being done
* the SourceForge ticket numbers (or shortened 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 webmaster(s) -- currently David Sewell, with assistance from Kevin Hawkins -- 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 to elements because its availability is thought to invite tag abuse. One principle used by the Technical Council is that if an element is repeatable and is something for which there can be different classifications, it should have @type.

== 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

2015-02-24T10:41:27Z

James: /* 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 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 in [http://tei.sourceforge.net/ SourceForge].
# 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 SourceForge Subversion). If it is not a real issue, sometimes the ticket will just be closed. If you do not have developer access on sourceforge you'll need to ask someone who does to re-open the ticket if you want to raise it again. 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 SourceForge 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 SourceForge 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 David Sewell (Virginia) and Kevin Hawkins (North Texas). 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 other systems administrators 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 [http://tei.sourceforge.net/ the TEI's SourceForge 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://tei.sourceforge.net/ the SourceForge system]
* acting as SIG coordinator
* liaising for and reporting on Council activities at all Board meetings
* reflecting Council wishes in Board discussions
* budgeting Council expenses,
* 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.

=== 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 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 "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.

=== 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 unsworth AT brandeis.edu.

Use the TEI Travel expense form available here: http://www.tei-c.org/Admin/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? ===

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 SourceForge 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 SourceForge 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 sourceforge. 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? ===

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 SourceForge? ===
All members of Council are made 'developers' on the SourceForge TEI Project 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 Subversion 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 SourceForge ==

=== 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_Subversion.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 subversion repository? ===

# Go to https://lists.sourceforge.net/lists/listinfo/tei-notify .
# Subscribe under your SourceForge email address (which you can find at http://sourceforge.net/project/memberlist.php?group_id=106328 ).

=== How do I use Subversion? ===

The TEI stores its working files in the TEI Sourceforge Subversion Repositories, with read access to anyone who wishes. See the [http://www.tei-c.org/Guidelines/P5/get.xml instructions]. Write access is reserved for those who are developers on the SourceForge project. To request developer status, contact one of the project admins, whose usernames are given in bold on [http://sourceforge.net/project/memberlist.php?group_id=106328 the SourceForge list of users].

Note that you will have to enter your password each time you access Subversion. A way around this (which causes a security risk) is to create a public/private key pair based on no passphrase and upload your public key to SF. There is a [http://www.linuxproblem.org/art_9.html description of how this process works in general], and [https://sourceforge.net/p/forge/documentation/SSH%20Keys/ some hard-to-follow instructions specific to SourceForge].

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

It is beneficial to all those looking at the TEI Subversion 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:
* an explanation to a useful level of detail about what you did
* a mention of why this is being done
* the SourceForge ticket numbers (or shortened 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 webmaster(s) -- currently David Sewell, with assistance from Kevin Hawkins -- 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 to elements because its availability is thought to invite tag abuse. One principle used by the Technical Council is that if an element is repeatable and is something for which there can be different classifications, it should have @type.

== 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]]

Council agenda 2015-01

2015-01-30T13:58:11Z

James:

== Teleconference 2015-01-30 14:00 GMT ==

* Welcome new members
* (Re-)review of actions [http://www.tei-c.org/Activities/Council/Meetings/tcm63.xml from last F2F] / [http://www.tei-c.org/Activities/Council/Meetings/tcm64.xml from last telco] / 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)
* Update on Oxygen plugin test builds (MH)
* 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

2015-01-30T10:27:36Z

James:

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]]
|[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]]

TEI-Council-FAQ

2015-01-06T17:56:55Z

James: /* How is the TEI Technical Council Chair elected? */

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 in [http://tei.sourceforge.net/ SourceForge].
# 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 SourceForge Subversion). If it is not a real issue, sometimes the ticket will just be closed. If you do not have developer access on sourceforge you'll need to ask someone who does to re-open the ticket if you want to raise it again. 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 SourceForge 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 SourceForge 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 David Sewell (Virginia) and Kevin Hawkins (North Texas). 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 has also invited a representative of the Board to the Council mailing list and meetings. Currently, this is Lou Burnard as non-voting board representative. The TEI-C Webmaster (currently David Sewell) is 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 [http://tei.sourceforge.net/ the TEI's SourceForge 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://tei.sourceforge.net/ the SourceForge system]
* acting as SIG coordinator
* liaising for and reporting on Council activities at all Board meetings
* reflecting Council wishes in Board discussions
* budgeting Council expenses,
* 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, "Instant Runoff Voting" method, a single winner, "ranked enhanced" ballot type, and 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.

=== 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 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 "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.

=== 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 unsworth AT brandeis.edu.

Use the TEI Travel expense form available here: http://www.tei-c.org/Admin/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? ===

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 SourceForge 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 SourceForge 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 sourceforge. 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? ===

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 SourceForge? ===
All members of Council are made 'developers' on the SourceForge TEI Project 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 Subversion 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 SourceForge ==

=== 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_Subversion.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 subversion repository? ===

# Go to https://lists.sourceforge.net/lists/listinfo/tei-notify .
# Subscribe under your SourceForge email address (which you can find at http://sourceforge.net/project/memberlist.php?group_id=106328 ).

=== How do I use Subversion? ===

The TEI stores its working files in the TEI Sourceforge Subversion Repositories, with read access to anyone who wishes. See the [http://www.tei-c.org/Guidelines/P5/get.xml instructions]. Write access is reserved for those who are developers on the SourceForge project. To request developer status, contact one of the project admins, whose usernames are given in bold on [http://sourceforge.net/project/memberlist.php?group_id=106328 the SourceForge list of users].

Note that you will have to enter your password each time you access Subversion. A way around this (which causes a security risk) is to create a public/private key pair based on no passphrase and upload your public key to SF. There is a [http://www.linuxproblem.org/art_9.html description of how this process works in general], and [https://sourceforge.net/p/forge/documentation/SSH%20Keys/ some hard-to-follow instructions specific to SourceForge].

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

It is beneficial to all those looking at the TEI Subversion 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:
* an explanation to a useful level of detail about what you did
* a mention of why this is being done
* the SourceForge ticket numbers (or shortened 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 webmaster(s) -- currently David Sewell, with assistance from Kevin Hawkins -- 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 to elements because its availability is thought to invite tag abuse. One principle used by the Technical Council is that if an element is repeatable and is something for which there can be different classifications, it should have @type.

== 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]]

Council agenda 2014-12

2014-12-05T13:57:18Z

James:

== Teleconference 2014-12-05 14:00 GMT ==

* Review of Actions (See minutes at [http://www.tei-c.org/Activities/Council/Meetings/tcm63.xml Minutes from F2F])
* 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)
* Update on [https://sourceforge.net/p/tei/feature-requests/443/ global @resp]; detailed implementation plan is [http://wiki.tei-c.org/index.php/Global_@resp_attribute on the wiki] for everyone to check through before it's done (MH)
* Date of next release; release technician
* Mentoring new members (MH)
* list further items here

Minutes Google Doc at: [https://docs.google.com/document/d/1A_NSVUIBHweVgWWc7xlqYU4BvgcIiEnMORh0Dsn22ME/edit?usp=sharing google doc minutes draft]

Council agenda 2014-12

2014-12-05T13:56:59Z

James:

== Teleconference 2014-12-05 14:00 GMT ==

* Review of Actions (See minutes at [http://www.tei-c.org/Activities/Council/Meetings/tcm63.xml])
* 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)
* Update on [https://sourceforge.net/p/tei/feature-requests/443/ global @resp]; detailed implementation plan is [http://wiki.tei-c.org/index.php/Global_@resp_attribute on the wiki] for everyone to check through before it's done (MH)
* Date of next release; release technician
* Mentoring new members (MH)
* list further items here

Minutes Google Doc at: [https://docs.google.com/document/d/1A_NSVUIBHweVgWWc7xlqYU4BvgcIiEnMORh0Dsn22ME/edit?usp=sharing google doc minutes draft]

Council agenda 2014-12

2014-12-05T11:52:10Z

James:

== Teleconference 2014-12-05 14:00 GMT ==

* Review of Actions (See minutes at [http://www.tei-c.org/Activities/Council/Meetings/tcm63.xml])
* 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)
* Update on [https://sourceforge.net/p/tei/feature-requests/443/ global @resp]; detailed implementation plan is [http://wiki.tei-c.org/index.php/Global_@resp_attribute on the wiki] for everyone to check through before it's done (MH)
* list further items here

Minutes Google Doc at: [https://docs.google.com/document/d/1A_NSVUIBHweVgWWc7xlqYU4BvgcIiEnMORh0Dsn22ME/edit?usp=sharing]

Council agenda 2014-12

2014-12-03T16:50:43Z

James:

== Teleconference 2014-12-05 14:00 GMT ==

* Review of Actions
* list items here

Council agenda 2014-12

2014-12-03T16:49:49Z

James: Created page with "== Teleconference 2014-12-05 14:00 GMT == * list items here"

== Teleconference 2014-12-05 14:00 GMT ==

* list items here

Council

2014-12-03T16:49:05Z

James: /* 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-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]]

TEI-Council-FAQ

2014-12-02T14:26:56Z

James:

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 in [http://tei.sourceforge.net/ SourceForge].
# 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 SourceForge Subversion). If it is not a real issue, sometimes the ticket will just be closed. If you do not have developer access on sourceforge you'll need to ask someone who does to re-open the ticket if you want to raise it again. 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 SourceForge 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 SourceForge 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.village.virginia.edu TEI Council mailing list owner], currently this is David Sewell in Virginia. There is also a 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 has also invited a representative of the Board to the Council mailing list and meetings. Currently, this is Lou Burnard as non-voting board representative. The TEI-C Webmaster (currently David Sewell) is 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 [http://tei.sourceforge.net/ the TEI's SourceForge 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://tei.sourceforge.net/ the SourceForge system]
* acting as SIG coordinator
* liaising for and reporting on Council activities at all Board meetings
* reflecting Council wishes in Board discussions
* budgeting Council expenses,
* 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 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, "Instant Runoff Voting" method, a single winner, "ranked enhanced" ballot type, and 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.)

== 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.

=== 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 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 "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.

=== 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 unsworth AT brandeis.edu.

Use the TEI Travel expense form available here: http://www.tei-c.org/Admin/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? ===

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 SourceForge 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 SourceForge 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 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 sourceforge. Council-specific issues should be raised on the council mailing list, after having reviewed any previous discussion on the topic in the [http://lists.village.virginia.edu/pipermail/tei-council/ council mailing list archives].

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

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 SourceForge? ===
All members of Council are made 'developers' on the SourceForge TEI Project 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 Subversion 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 SourceForge ==

=== 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_Subversion.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 subversion repository? ===

# Go to https://lists.sourceforge.net/lists/listinfo/tei-notify .
# Subscribe under your SourceForge email address (which you can find at http://sourceforge.net/project/memberlist.php?group_id=106328 ).

=== How do I use Subversion? ===

The TEI stores its working files in the TEI Sourceforge Subversion Repositories, with read access to anyone who wishes. See the [http://www.tei-c.org/Guidelines/P5/get.xml instructions]. Write access is reserved for those who are developers on the SourceForge project. To request developer status, contact one of the project admins, whose usernames are given in bold on [http://sourceforge.net/project/memberlist.php?group_id=106328 the SourceForge list of users].

Note that you will have to enter your password each time you access Subversion. A way around this (which causes a security risk) is to create a public/private key pair based on no passphrase and upload your public key to SF. There is a [http://www.linuxproblem.org/art_9.html description of how this process works in general], and [https://sourceforge.net/p/forge/documentation/SSH%20Keys/ some hard-to-follow instructions specific to SourceForge].

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

It is beneficial to all those looking at the TEI Subversion 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:
* an explanation to a useful level of detail about what you did
* a mention of why this is being done
* the SourceForge ticket numbers (or shortened 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 webmaster(s) -- currently David Sewell, with assistance from Kevin Hawkins -- 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 to elements because its availability is thought to invite tag abuse. One principle used by the Technical Council is that if an element is repeatable and is something for which there can be different classifications, it should have @type.

== 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

2014-11-18T14:34:31Z

James: /* What is the "Durand Conundrum"? */

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 in [http://tei.sourceforge.net/ SourceForge].
# 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 SourceForge Subversion). If it is not a real issue, sometimes the ticket will just be closed. If you do not have developer access on sourceforge you'll need to ask someone who does to re-open the ticket if you want to raise it again. 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 SourceForge 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 SourceForge 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.village.virginia.edu TEI Council mailing list owner], currently this is David Sewell in Virginia. There is also a 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 has also invited a representative of the Board to the Council mailing list and meetings. Currently, this is Lou Burnard as non-voting board representative. The TEI-C Webmaster (currently David Sewell) is 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 [http://tei.sourceforge.net/ the TEI's SourceForge 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
* assigning tickets in [http://tei.sourceforge.net/ the SourceForge system]
* acting as SIG coordinator
* liaising for and reporting on Council activities at all Board meetings
* reflecting Council wishes in Board discussions
* budgeting Council expenses,
* 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 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, "Instant Runoff Voting" method, a single winner, "ranked enhanced" ballot type, and 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.)

== 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.

=== 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 the work on Pure ODD elements for content models and datatypes has cut the gordian knot of this problem.

=== 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 "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.

=== 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 unsworth AT brandeis.edu.

Use the TEI Travel expense form available here: http://www.tei-c.org/Admin/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? ===

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 SourceForge 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 SourceForge 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 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 sourceforge. Council-specific issues should be raised on the council mailing list, after having reviewed any previous discussion on the topic in the [http://lists.village.virginia.edu/pipermail/tei-council/ council mailing list archives].

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

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 SourceForge? ===
All members of Council are made 'developers' on the SourceForge TEI Project 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 Subversion 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 SourceForge ==

=== 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_Subversion.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 subversion repository? ===

# Go to https://lists.sourceforge.net/lists/listinfo/tei-notify .
# Subscribe under your SourceForge email address (which you can find at http://sourceforge.net/project/memberlist.php?group_id=106328 ).

=== How do I use Subversion? ===

The TEI stores its working files in the TEI Sourceforge Subversion Repositories, with read access to anyone who wishes. See the [http://www.tei-c.org/Guidelines/P5/get.xml instructions]. Write access is reserved for those who are developers on the SourceForge project. To request developer status, contact one of the project admins, whose usernames are given in bold on [http://sourceforge.net/project/memberlist.php?group_id=106328 the SourceForge list of users].

Note that you will have to enter your password each time you access Subversion. A way around this (which causes a security risk) is to create a public/private key pair based on no passphrase and upload your public key to SF. There is a [http://www.linuxproblem.org/art_9.html description of how this process works in general], and [https://sourceforge.net/p/forge/documentation/SSH%20Keys/ some hard-to-follow instructions specific to SourceForge].

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

It is beneficial to all those looking at the TEI Subversion 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:
* an explanation to a useful level of detail about what you did
* a mention of why this is being done
* the SourceForge ticket numbers (or shortened 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 webmaster(s) -- currently David Sewell, with assistance from Kevin Hawkins -- 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 to elements because its availability is thought to invite tag abuse. One principle used by the Technical Council is that if an element is repeatable and is something for which there can be different classifications, it should have @type.

== 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]]

Council agenda 2014-11

2014-11-17T03:46:09Z

James: /* Draft Agenda for TEI Technical Council Meeting 2014-11-17 to 2014-11-19 */

=Draft Agenda for TEI Technical Council Meeting 2014-11-17 to 2014-11-19=

Minutes Document at https://docs.google.com/document/d/16WVX4FEH5EfLJxY3bwlYD_9EBVP5ucS2e_QiOV9mxew/edit?usp=sharing

== Monday 17 November 2014 ==
09:00 - 10:30
* TEI Simple
* Pure ODD
Apologies: discussion of contextual dependency issues not yet started.
Do we need <textNode>? or <mixedContent>? Decision is holding up completion of [http://tei.it.ox.ac.uk/Oxford/2014-10-odds/pureODDtutorial.xml [introductory tutorial]].
* 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])
* ISO-TEI Workgroup on Speech Transcription (LB; see [http://bit.ly/1jyZC37 "final draft oct 2014"]) recommends one new element.
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)
* TEI Validation Service (PSt)
* 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-10T17:06:38Z

James: /* 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?

== Tuesday 18 November 2014 ==
09:00 - 10:30
*
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-10T17:03:22Z

James:

=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?

== Tuesday 18 November 2014 ==
09:00 - 10:30
*
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
*
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-10T17:03:04Z

James: Created page with "=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 * Correspon..."

=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?

== Tuesday 18 November 2014 ==
09:00 - 10:30
*
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 2 July 2014 ==
09:00 - 10:30
*
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

2014-11-10T16:59:07Z

James:

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 Raleigh, 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-10

2014-10-03T09:17:06Z

James: /* Teleconference Agenda */

==Teleconference Agenda==
* TEI Conference, Members Meeting, and Elections (JC)
* TEI Simple (SR)
* Update on CorrespDesc (PWS)
* November Face to Face (HC)
*
*
* your items here
*
*
* AOB

Council agenda 2014-10

2014-10-03T09:13:05Z

James: /* Teleconference Agenda */

==Teleconference Agenda==
* Add item here with your initials
* TEI Conference, Members Meeting, and Elections (JC)
* TEI Simple (SR)
* Update on CorrespDesc (PWS)
* November Face to Face (HC)
*
*
* your items here
*
*
* AOB

Council agenda 2014-10

2014-09-30T19:02:29Z

James: starting page

==Teleconference Agenda==
* Add item here with your initials
* TEI Simple (SR)

Council

2014-09-30T19:01:18Z

James: /* 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-10-03 Teleconference
|[[Council agenda 2014-10]]
|final minutes
|
|-
|2014-08-01 Teleconference
|[[Council agenda 2014-08]]
|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-08

2014-07-31T23:31:09Z

James:

Please add your agenda items below:

* Add items here
* Next Release (SB/EM); release cut-off-date
* TEI Simple (SR)
* Reminder to feed back thoughts on CorrespDesc (PWS)
* Autumn Face2Face (HC)
* List Types (MH/SR)
* HackAThon at TEI Conf?
* Reminder of tickets
* AOB

Next meeting: Friday 3 October

Council agenda 2014-08

2014-07-31T23:19:13Z

James:

Council agenda 2014-08

2014-07-29T15:37:03Z

James:

Please add your agenda items below:

* Add items here
* TEI Simple (SR)
* Reminder to feed bakc thoughts on CorrespDesc (PWS)
* Autumn Face2Face (HC)
* Next Release (SB/EM)
* List Types (MH)
* HackAThon at TEI Conf?

2014-06-29T09:17:40Z

James:

Draft Agenda for TEI Technical Council Meeting 2014-06-30 to 2014-07-02.

== Monday 30 June 2014 ==
09:00 - 10:30
* TEI Simple
* PureODD: Can Lou tell us where we're at and where we're going, and Sebastian talk about implementation (working, planned, and blue-sky)?
** whether it makes sense to have @allowText on sub elements of <content>
** what a set of elementRef as direct children of <content> means
** what the same thing means with @allowText
** when and how to convert Gidlines to Pure ODD
** testing testing testing
* TEI DH2014 HackAThon
15:00 - 17:00
* Ticket implementation or other TEI Work
18:00-
* Picnic in University Parks. (James will lead from Rewley House)

== Tuesday 1 July 2014 ==
09:00 - 10:30
* Text directionality additions: final reading and approval
* Global Applicability of att.responsibility
* Autumn Face-to-Face meeting
10:30 - 13:00
* Tickets
13:00 - 14:00
* Lunch (Rewley Dining Room)
14:00 - 15:00
* Tickets Recap or other discussion
15:00 - 17:00
* Ticket implementation or other TEI Work
18:00-
* Supper: Old Bookbinders Ale House http://oldbookbinders.co.uk/

== Wednesday 2 July 2014 ==
09:00 - 10:30
* MDH on Guidelines translation (with help from FC): Italian and German teams are not making much progress. Is there anything we can do?
* TEI Standoff and Linked Data representations
* TEI Future Developments (e.g. Roadmap to P6, Bluesky thinking, etc.)
10:30 - 13:00
* Ticket Discussion and Assignment
13:00 - 14:30
* Lunch (Pierre Victoire)
14:30 - 15:00
* Tickets Recap and other discussion
15:00 - 17:00
* Ticket implementation or other TEI Work
18:00 -
Supper: restaurant to be agreed.

[[Category:Council]]