TEIWiki - User contributions [en]

DH2014Hackathon-Projects

2014-07-06T17:02:37Z

Rahtz: /* Develop the MS description framework */

= DH2014 Hackathon Project Discussion Page =

== Let's Hack ==

A suggestion for how to proceed based on the range of proposals and the range of participants. The group is likely to be able to sustain 2 or at most 3 projects in the time frame allotted. Some suggestions; please modify, develop or otherwise shape to your liking!

=== Suggested setup using Git ===

There is a Git repository at https://github.com/TEIC/Hackathon which can be used for any group during the Hackathon. Sebastian Rahtz can add people to the TEI group on request so that they have write access. You can use any Git client, obviously. If you don't have a client setup
already and are on a Mac, you'll find https://mac.github.com/ easy to set up and use. If you possibly can, get your account and setup ready before the meet.

This repository is synchronized with a web server at http://tei.it.ox.ac.uk/Hackathon/ every minute. This web server has a CORS setup, which should allow cross-site scripting to work for any
group working with JSON or other Ajax technique.

To test this, clone the Git repository on your local laptop and open the file map/maptest.html in your browser. It should read JSON data from
http://tei.it.ox.ac.uk/Hackathon/map/objects.json and display it on a map. If you add more JSON data files to the repository, and push them up to Github, they should appear on the web server quite quickly; similarly this can be used to "publish" HTML.

Sebastian will be available during the Hackathon to wrangle the web server as needed.

=== ODD visualizer ===

A group might try to put together a plan and start to code up an ODD visualizer. ODD is a literate programming language for XML schemas written by the TEI, and which is used to define the TEI schema. An ODD visualizer might be a component of an ODD customization tool such as the successor of Roma, and could provide information to a user about what modules they have included in their TEI schema, or what modification they have made.

The group should start by discussing what to visualize, perhaps including some TEI users who has experience in customization.

'''Resources:''' About ODD [http://www.tei-c.org/Support/Learn/odds.xml Getting Started with P5 ODDs], [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/USE.html Guidelines Chapter 23: Using the TEI] and a look at [http://www.tei-c.org/Roma/ Roma], the tool that is currently in use for generating TEI customizations.

--[[User:Elli Bleeker|Elli Bleeker]] 16:05, 4 July 2014 (CEST) I know of some digital edition projects that are a priori TEI compliant but have added their own custamizations if the TEI Guidelines did not offer a sufficient solution for the <nowiki>"challenge"</nowiki> posed by the text. I can imagine there are more projects that do so. Is that meant by <nowiki>"modification"</nowiki> of the TEI schema?
It seems the ODD visualizer might be a good addition to the authorial workflow as described below, if it offers the editors insight in their specific text encoding methods.

[[User:Elena Spadini|Elena Spadini]] 12:13, 5 July 2014 (CEST) (I'm not sure this is the right place for adding names to a project as Elli wrote us, but) I would like to work on it!

[[User:Raffaele.viglianti|Raffaele.viglianti]] 13:40, 6 July 2014 (CEST) I'd happily work on this

--[[User:Rahtz|Rahtz]] 17:50, 6 July 2014 (CEST) Elli - a modification is often simply specifying a subset of the TEI, ie removing elements you don't need. Visualizing just this relationship is itself quite useful; the proof of concept at http://tei.it.ox.ac.uk/Byzantium/ demonstrates a trivial example. In an ideal alternate work, the visualization would dynamic. Ie it would show a list of modules, and you could click on one to remove the elements in it, and that would trigger writing an ODD file.

=== Basic framework for rendering a document and creating simple visualizations ===

This project could be quite extensive, so the group should begin by selecting components that they can manage.

The proposed outcome is to be able to display (or at least mine) a document for salient features, and to produce output generic enough that it can be passed to either mapping or to other visualization software. Or perhaps to the NY Times Pourover js library. One possible way to to do this is to decide on a json data structure, as that is a popular format for visualization libraries.

--[[User:Frederike Neuber|Frederike Neuber]] 08:08, 3 July 2014 (CEST) Are you referring to a particular visualization software on which it might be useful to take a quick look before the hackathon?

--[[User:Elli Mylonas|Elli Mylonas]] 11:27, 4 July 2014 (CEST) Frederike has a good comment - are there suggestions? Google Maps is one idea. Leaflet, and D3 (more complex) are others. Thoughts?

--[[User:Rahtz|Rahtz]] 17:02, 6 July 2014 (CEST) I would suggest we limit ourselves for this project to Leaflet (mapping) and D3 (graphs) with its companion C3. Both have loads of examples and addons. Leaflet rather than Google Maps because it doesn't need API keys etc, and can use other tiles easily. The key thing here is to proof of concept - get a visualization up and running quickly, then tweak it. If its successful, recoding it later in another library is not so hard. Note, however, that we come up against cross-site scripting when we read JSON in an HTML file. See Setup section above.

I like the idea that we take some texts and a) isolate a set of features that can be extracted for looking at, b) work out what they look like in JSON, and c) practice visualizing them in some way. I have added an example XSLT script at https://github.com/TEIC/Hackathon/blob/master/visualization/teitojson.xsl which shows how you'd grab (in this case persName) elements from a TEI XML file and write a JSON file. Demo result at http://tei.it.ox.ac.uk/Hackathon/visualization/test.json

=== Develop the MS description framework ===

This was one of the proposed projects that got a lot of comments. It could be developed along the lines of the comments, and generalized a bit.

[[User:Alexander Czmiel|Alexander Czmiel]] 14:20, 4 July 2014 (CEST) Maybe I don't get it, but it seems to me this project has the same aims like "Basic framework for rendering a document". Anyway, rendering TEI documents is an imortant issue which has not been adressed enough in the past. Especially when looking on complex markup such as recommended by the Genetic Markup SIG.
There are already a few approaches which try to do exactly the same, we want to do here: build a generic framework to publish TEI documents online. There is eLaborate (http://elaborate.huygens.knaw.nl/) from Den Haag, xMod (http://www.cch.kcl.ac.uk/xmod/) from London, DENQ from Rome, and SADE (best/current version on Github by vronk: https://github.com/vronk/SADE) which we try to build in Berlin/Göttingen/Wien. To a certain point OMEKA (http://www.omeka.net/) could be used as well, I think. There are many more, I don't know of. So please don't let us start from the scratch with a new project.

--[[User:Elli Bleeker|Elli Bleeker]] 14:56, 4 July 2014 (CEST) I agree it would be pointless to start from scratch. But it might be worth considering to further develop one of the abovementioned approaches. I am not familiar with all of them, but most tend to fail once the textual genetics becomes more complex. The fact that many of the proposed projects in this Hackathon are aimed at the rendering of complex TEI mark up, suggests that this is one of the most important needs of textual scholars and that there is still no sufficient way to do so.

--[[User:Frederike Neuber|Frederike Neuber]] 19:27, 4 July 2014 (CEST) It seems we have all different understandings of the project's descriptions - I will tell you mine too: 
In my opinion the two project aim different results, even if the workflow will be partly the same. 
The "rendering complex markup.." aims to offer in a creative visualization of the extracted data, so this project will be about including visualization software which supports data visualization beyond lists and timelines. 
The "MS description.." aims (or at least it did in the beginning) to create a framework which is applicable to each TEI-document containing a <msDesc> part and includes both displaying the <msDesc> content (in an linear way, no tricky visualization) and search and browse functions. The scope of this project is to provide in the end a set of files which anyone can use to render a <msDesc> part. 
So far.. can somebody bring light into the darkness please? :)

[[User:Patrik Granholm|Patrik Granholm]] 23:35, 4 July 2014 (CEST) My initial proposal was to create a simple search and browsing interface for MS descriptions which would be general enough to be used by other similar projects. But perhaps it is too specific. An interface for TEI-files in general would probably be more useful. The idea is that everything should be well documented so that people with limited programming skills would be able to modify the code to suit their needs. It would be more like an eXist template than a finished product.

[[User:Elena Spadini|Elena Spadini]] 12:08, 5 July 2014 (CEST) I don't think that it is too specific and an interface for TEI files in general is probably too wide for one day. For sure there are a lot of projects flourishing in this way (not eLaborate that is at a certain point TEI compliant but not at all TEI based), as everyone using TEI deals with the problems and find more or less home made solutions. But if during the Hackathon something can be started and finished, it would be a really good result!

--[[User:Frederike Neuber|Frederike Neuber]] 15:55, 5 July 2014 (CEST) Maybe we could decide whether we want to render the metadata or the text. I think some templates for rendering the <teiHeader> with focusing on search options (searching for certain fields, combining them, faceted search) would be nice. 
Can someone provide some XML files to work with?

[[User:Patrik Granholm|Patrik Granholm]] 08:55, 6 July 2014 (CEST) I have a few preliminary MS descriptions from our cataloguing project, and quite a large collection of MS descriptions from other projects which we could work with.

--[[User:Rahtz|Rahtz]] 19:02, 6 July 2014 (CEST) I agree that starting a new framework isn't a good idea, but I do think there is a future in taking just the components of the transcription module and doing rendering of those. Its a horribly open-ended exercise, though.

=== Discussing, working out and documenting best practices for an authoring workflow ===

Projects that last for many years, have many people working on them, and comprise large amounts of material need to ensure that work is being done efficiently, produce accurate output, and move files through transformations and validations. Good workflows can be enhanced by both tools and best practices. The outcome of this project could be a document with explanation and examples of authoring/encoding/proofreading/version control workflows with a focus on software tools.

--[[User:Elli Bleeker|Elli Bleeker]] 15:22, 4 July 2014 (CEST) Would we aim at enhancing the workflow of existing projects or suggest best practices for future projects? It would be very interesting to see whether it is possible to distinguish a best practice for an authoring workflow. Normally projects that run for many years and started <nowiki>"back in the days"</nowiki> have developed their own ad hoc workflow. They happily admit to have done things differently witht the knowledge of today. Of course the workflow depends upon the people working on it (trained editors, volunteers through crowd-sourcing...).
Perhaps the outcome would be several different workflows, depending on the type of material, the objectives of the project and the people collaborating on it.

== Participants ==

* [http://mith.umd.edu/people/person/raffaele-viglianti/ Raffaele Viglianti], University of Maryland
* [http://www.patrikgranholm.com Patrik Granholm], Uppsala University Library: [http://www.manuscripta.se Greek Manuscripts in Sweden. A Digitization and Cataloguing Project]
* [http://online.uni-graz.at/kfu_online/visitenkarte.show_vcard?pPersonenId=9570FBD84B50B383&pPersonenGruppe=3 Frederike Neuber], DiXiT - research fellow at Graz University - Austrian Centre for Digital Humanities
* Felix Lange, Academy of Sciences and Literature | Mainz, Project IBR (http://www.spatialhumanities.de)
* Emmanuelle Morlock, CNRS, HISoMA Laboratory (Histoire et Sources des mondes antiques / History and Origins of the Antique World)
* [https://www.uantwerpen.be/en/staff/elli-bleeker/ Elli Bleeker], PhD student in Digital Humanities at Antwerp University; research fellow at DiXiT
* Magdalena Turska, University of Oxford
* Nick Laiacona, Performant Software Solutions LLC www.performantsoftware.com
* Elizabeth Maddock Dillon, Professor of English and CoDirector of NULab for Texts, Maps, and Networks, Northeastern University, Boston, MA USA
* [http://steinheim-institut.de/wiki/index.php/Mitarbeiter:Thomas_Kollatz Thomas Kollatz], Steinheim-Institute for German-Jewish History: [http://steinheim-institut.de/cgi-bin/epidat epidat]
* Elena Spadini, Huygens Ing

* Sebastian Rahtz, University of Oxford
* James Cummings, University of Oxford
* [http://www.i-d-e.de/mitglieder/alexander-czmiel Alex Czmiel], Berlin-Brandenburg Academy of Sciences and Humanities
* Hugh Cayless, Duke University
* Elli Mylonas, Brown University

== Procedure ==

We will be using the wiki as a place for comments and discussion. The projects each participant proposed are all listed below. Ideally, the hackathon will be focussed around one or two projects that are useful to everyone. The participants are all experienced with TEI in various capacities, but they are not all skilled programmers. The hackathon would be a success if the outcome of the one day event was e a good start on one or two useful pieces of TEI related software. In order to achieve this, we should collectively decide on projects that are interesting, useful, generalizable, and do-able! We should also try to capitalize on everyone's skill set, and try to plan the event in such a way that we can all contribute to something.

You are all welcome to introduce yourselves, by adding a description of a few sentences to the list of participants above. And please, edit, correct and comment on the projects. We are also inviting the TEI Council and Board and other interested parties to look in on the discussions.

== Proposed Projects ==

=== Mormon City Planning: ===
when early Mormonism ventured from Kirtland, Ohio, into Missouri, their prophet Joseph Smith Jr provided a revelation for the plat (city layout) of the new Zion (http://urbanplanning.library.cornell.edu/DOCS/smith.htm; http://zomarah.files.wordpress.com/2010/10/firstplatofzion.png), which was subsequently applied in the settlement of Far West, Missouri, for which two plats exist, one on sheepskin (https://www.lds.org/bc/content/shared/content/images/gospel-library/manual/32502/15-02 b.gif) in private possession and one on paper at BYU University (there is no online copy of this, but I have obtained a digital copy from BYU with their permission); however these plats were not only used to sketch out the city, but also to assign lots to settlers, and thus show secondary markup in pencil to allocate houses, redraw lot boundaries, etc; (http://zomarah.files.wordpress.com/2010/10/platoffarwestbig.png)

'''Comments:'''
* A clarification: What would the project strive to accomplish? Is this a visualization? georeferencing based on markup?
* [[User:Thomas Kollatz|Thomas Kollatz]] 11:57, 1 July 2014 (CEST) https://www.lds.org/bc/content/shared/content/images/gospel-library/manual/32502/15-02 error 404 - not found; maybe visualization: text-information encoded in TEI related to city layout ("plat") in SVG ?

=== ODD Customization visualizer ===
A web-based tool to visualize any ODD customization against TEI-all. This could be useful when working on a customization (with Roma, or manually) to quickly and visually check that the ODD is still TEI-conformant and see how it diverges from the standard.
I started working on a basic D3 visualization a couple of years ago, but haven't really touched the code since:https://github.com/raffazizzi/ODDViz I only restructured the repository a bit before sending this proposal.

'''Comments'''
A simple demo: https://dl.dropboxusercontent.com/u/2443674/ODDViz/index.html --[[User:Raffaele.viglianti|Raffaele.viglianti]] 03:02, 3 July 2014 (CEST)

=== ACE-based Web editor ===

MITH, at the University of Maryland has been working on an ACE-based web editor able to validate tei-all files in the browser and provide ODD-based contextual help (e.g. suggesting valid options when entering a new element).
The grant that funded this work is now over, but there's plenty more to do. This is the GitHub repository: https://github.com/umd-mith/angles

'''Comments:'''

=== MS Description Display Framework ===
To create a simple web interface which would provide basic functionalities like browsing, searching and displaying TEI-files containing manuscript descriptions. The interface could be built using a Ubuntu server with [http://nginx.org nginx], and [http://exist-db.org eXist-db] following the setup guide and scripts provided by [https://github.com/grantmacken/nginx-eXist-ubuntu Grant Macken]. I have already made some preliminary work on an eXist-db web interface and posted the code in our [https://github.com/manuscripta GitHub repository]. This could be used as a starting point for further development. A possible goal for the hackathon could be to create an advanced search form in XQuery which would display snippets of the descriptions in the search results using the transform function with our XSL stylesheet, with links to the full description. All of the code, with detailed documentation, would be made public on GitHub for others to reuse and modify for their own projects. I think this would be beneficial to the TEI community at large, and especially to other cataloguing projects.

'''Comments:'''

* I believe this would be really useful project, especially if we build it not only having this particular purpose of MS descriptions in mind, but something more general, so other users would potentially swap only source files and stylesheets and would have a basic working website. [[User:Magdalena Turska|Magdalena Turska]] 11:00, 23 June 2014 (CEST)
* me too – more general features almost every project will need after swapping source files and stylesheets: navigation to next page/object ; or: navigation to next entry/object in chronological order, full text search everywhere resp in particular div's (type="edition") etc. [[User:Thomas Kollatz|Thomas Kollatz]] 12:09, 1 July 2014 (CEST)
* I am definitely open to creating a more general display framework in eXist. Perhaps we could make use of Joe Wicentowski’s [http://digital.humanities.ox.ac.uk/dhoxss/2011/presentations/Wicentowski-XMLDatabases-materials.zip Punch eXist tutorial] from DHOxSS 2011. [[User:Patrik Granholm|Patrik Granholm]] 11:16, 2 July 2014 (CEST)

=== Medieval Text Edition ===

<strike>
Project isn't advanced enough to suggest concrete task, but the topic of interest is focussed around a digital scholarly edition of a medieval text (with corresponding images) encoded in XML/TEI. The edition will be enriched with palaeographical and codicological information (in both <text> and <teiHeader>) and the results can be visualized in a way which hopefully goes beyond the sometimes not very enlightening listing of data.</strike>

'''Comments:'''
Even now my project is not advanced enough to be used for the hackathon. I will join the discussions on the other projects. --[[User:Frederike Neuber|Frederike Neuber]] 22:05, 24 June 2014 (CEST)

=== Semantic Connections for Epigraphic Documents ===
I am currently working with epidoc documents in the context of the Project IBR. These documents, epigraphical editions from the catalogue "German Inscriptions Online" (inschriften.net), are (1) to be transformed into RDFtriples for semantic connection and for a finegrained quantificational analysis in a Triple Store, (2) XSLT transformed into HTMLDocuments for further annotation in the semantic annotator "Pundit"(thepund.it). I could surely contribute a programming task based on this points, but would also be happy to participate in another task, preferably based on "adding a TEI mode to a web editor".

'''Comments:'''

--[[User:Frederike Neuber|Frederike Neuber]] 23:02, 24 June 2014 (CEST) Who is responsible for this project and can provide further information?
I would be very interested in joining this project even if I can't offer material and even if I do not understand one step: how can you transform an epidoc document into RDF triples? Do you mean you generate RDF from the annotated entities (extracting them?)? And how do you do it, are there tools or software to support it?

[[User:Thomas Kollatz|Thomas Kollatz]] 12:12, 1 July 2014 (CEST) The [http://www.tei-c.org/oxgarage/ oxgarage] magic box contains already a tool converting TEI2RDF, if so – we should try it out and evaluate it if not - let's develop it …

[[User:Felix Lange|Felix Lange]]14:56, 4 July 2014 (CEST) Thomas Kollatz is right, this tool is quite mature by now, making a new development from scratch pointless. But is there a programmatic (e.g. ReST) interface to the converter? If not, let's do it! @Frederike, some further project informations can be found at www.spatialhumanities.de/ibr, our project website.

=== Zotero ===
Some TEI encoding project may need to use a "master bibliography" to group together all the bibliographic references that are used in a given text or collection of texts. Using the "masterfile" option in Oxygen give the user a convenient way of pointing to a reference without having to encode a ref each time it is used in a text or in a specific bibliographic section.
<pre>
<bibl type="fromStone">
<ptr target="#Breal1878"/>
<citedRange>15</citedRange>
</bibl>
</pre>

The bibliography can be inserted in a <back/> element with xinclude. But the question is how to use Zotero to create this file, update it and synchonize it with the biblographic masterfile.
Though incomplete, the workflow I use works like that :
* the entering of the bibliographic entries is done with zotero, in a group library
* the zotero database is then exported in xml using the "bibliontology_rdf" format (the TEI export format being to restrictive in its formatting choices : e.g. does'nt include "short titles" which are a requisite in epigraphy
* the bibliontology rdf is converted in TEI through XSLT in Oxygen (modifying existing xslt :https://github.com/paregorios/Zotero-RDF-to-TEI-XML)
* If the user wants to add a new reference in the masterbibliography or correct an entry, he or she has to do go to zotero and follow the whole workflow of export - tranform process. But the user might not have the user right to do so. And of course, there are some potential conflicting issues.

How to improve that workflow ? use a version control system like git or subversion ? or adding/modifying an entry in xml / tei and then updating the zotero group library via api ?

'''Comments:'''
--[[User:Elli Bleeker|Elli Bleeker]] 15:29, 1 July 2014 (CEST) It seems that working with subversion would improve the workflow a lot and at least illiminate the risk of conflicting issues. Of course users should have the right to work in the (seperate) xml file of the bibliographic masterfile and add/change references. Once completed, the xml file can be exported to Zotero. In short, this would mean a reverse of the current workflow.

=== Migrating value lists form CSS frameworks to ODD ===

The author mode of the Oxygen editor can be customized with custom css functions. A part from the function providing a more user-friendly and tag free visualization of the tei content, one of the fuction allow the user to edit attributes or simple elements values using combo boxes or check boxes. The "form controls" can display values collected from an xml schema. But these values can also be just in the oxygen css. This may be used in a workflow to test some choices before integrating them in a more consistent and persistant way in the ODD (then exported in the schema).

This could be useful in case you have user that may be ok to change the values in the css code but would be relunctant to get involved with the ODD editing / schema generation process.
cf. http://www.oxygenxml.com/doc/ug-editor/concepts/combo-box-editor.html#combo-box-editor

'''Comments:'''

--[[User:Raffaele.viglianti|Raffaele.viglianti]] 19:20, 16 June 2014 (CEST) This is interesting, would like to work on it. I would suggest to make it less tied to Oxygen and think in terms of CSS to ODD, for example to limit attribute values (e.g. hi[rend=italic])

[[User:Elena Spadini|Elena Spadini]] 00:13, 24 June 2014 (CEST) I'm not well-exeperienced with the author mode in oXygen and its customizations, but I would like to explore it working on this project.

=== Visualization of intertextual TEI content ===
[UPDATED on June 24th]

The focus is on the possibilities offered by TEI XML for encoding intertextuality. The case study concerns the personal library of an author and a digital edition of his work. The objective is to encode the material in such a way that the intertextual relations between the literary work and its external sources is visualized.

These -sometimes subtle- intertextual relationships provide insight into the nature of writing, all the more since the genesis of the literary work itself is already encoded in the edition (i.e. adds, dels, etc.). The envisioned result enables a user to study the writing process in detail as well as on a larger scale.

Material:
* detailed XML TEI transcription of the literary work concerned
* high quality digital facsimiles of the author's personal '''extant''' library
* rough transcriptions of the library books (based on OCR)

'''Comments:'''

* Clarification: is the project about the visualization? the relationships? More detail would be great.
*
--[[User:Elli Bleeker|Elli Bleeker]] 15:46, 1 July 2014 (CEST) The idea is to log the complete <nowiki>"path"</nowiki> of a citation: from a phrase underlined in a library book to the incorporation of that phrase in the author's work.
Currently, the intertextual references are encoded with [ref] tag in the XML TEI transcription of the literary work. The [ref]s refer to another xml file containing the transcriptions of the personal library. This file consists of [div]s, that contain anything from a complete library book to a small section (paragraph, phrase) from a library book.

The visualization of the intertextual relations comes in a later stage when transforming the documents. I wonder whether it is possible to change or improve this encoding.

=== Rendering Complex Markup ===
Rendering complex markup in an innovative and playful way: reconstructing & visualizing author’s
geographical position by the dates of sending of his letters (taking uncertainty into account)

'''Comments:'''

[[User:Magdalena Turska|Magdalena Turska]] 12:36, 12 June 2014 (CEST)

Starting with a list of letters that have a place and date of sending the idea would be to present map overview of the author's journeys.
See the simple Google Map at https://mapsengine.google.com/map/edit?mid=z3q4AefiR7Us.kf1fVBHlu8qE

Fist ideas re visualisation:
* places color-coded with color getting darker to represent 'later' places
* similarly shaded lines along the routes between places
* animation with slider to show circle moving along the routes, size of the circle getting bigger with the uncertainty

Input data:
each letter has assigned place name and 1+ time intervals (notBefore to not After)

--[[User:Frederike Neuber|Frederike Neuber]] 22:25, 24 June 2014 (CEST)
Would it be a problem to work on different material? @TEI-experts
I would like to visualize the provenance of medieval manuscripts on a map, so even if I do not work with letters, the task is partly the same (extracting date and time from the <teiHeader> and visualizing it on a map). Then our scopes separate: Magdalena wants to reconstruct the journey, I want to visualize the chronology of different mss on one map.

[[User:Thomas Kollatz|Thomas Kollatz]] 15:56, 1 July 2014 (CEST)
I agree with [[User:Frederike Neuber|Frederike Neuber]]: the task is the same in all projects, where a spatio-temporal visualization makes sense: Extract date and time from header - and visualize the chronology of date/time and place on a map and/or timeline
/TEI/teiHeader/fileDesc/sourceDesc/msDesc/history/origin

=== Adding a TEI mode to a web editor ===
Title says it all!

'''Comments:'''

--[[User:Raffaele.viglianti|Raffaele.viglianti]] 19:20, 16 June 2014 (CEST) How does the [http://wiki.tei-c.org/index.php/DH2014Hackathon-Projects#ACE-based_Web_editor Angles] proposal above sound?

=== Juxta Script support ===
Adding support for Bengali text to Juxta Commons

'''Comments:'''
* This is fairly narrow.
[[User:Thomas Kollatz|Thomas Kollatz]] 15:57, 1 July 2014 (CEST) If Bengali then Hebrew (Arabic … right-to-left), please

=== Visualization ===
The archive of early Caribbean texts and images is a fairly large project which will be heavily encoded (and a portion of texts will be encoded by July). I'd like to explore ways of using the TEI to visualize relations between and among texts and elements of texts.

'''Comments:'''

--[[User:Elli Bleeker|Elli Bleeker]] 16:19, 1 July 2014 (CEST) What is the status of this project? I am also interested in finding ways to visualize relations between texts, perhaps there are similarities?

=== Jewish Sepulchral Headstones DB ===

Given that all headstones can be clearly located,
and about 20.000 (of total 26.000) inscriptions are dated,
and to a large extend can be distinguished by gender,
and also by language usage (hebrew, german, german in Hebrew letters, …),
they lend themselves to mining the epidat corpus for specific data facets and try to visualize the results "in an innovative and playful way".
#A challenging research questions could be the search for and visualization of the differences in word usage and specific idiomatic
## between different locations,
## within different periods (based on one or several locations),
## between inscriptions for men and inscriptions for women,
## between hebrew and non-hebrew inscriptions …
#Even more challenging is the search for inscriptions with very similar text coverage. These are quite difficult to discover by a simple full text search. The inscriptions are usually rather short, and the filter to develop has to consider the differentiating elements – usually names and dates – in order to determine, whether two text are identical or not.

All necessary information to answer this questions is contained in the metadata <teiHeader> and data <text> of each single record.
example – spatial and temporal metadata (date, country/region code, geo-coordinates, Thesaurus of Getty Names or OSM ID)
<history>
<origin>
<date notBefore='1621-08-17'>1621-08-17</date>
<country type="ISO_3166" key="XA-DE-HH">
Germany
<region>Hamburg</region>
</country>
<settlement type='city' key='tgn:7012310'>
Hamburg-Altona, Königstraße
<geogName>
Jüdischer Friedhof
<geo decls="#WGS">53.549373 9.950545</geo>
</geogName>
</settlement>
</origin>
</history>
example – gender-specific metadata (given according to ISO 5218:2004)
<particDesc>
<listPerson>
<person xml:id="hha-3361-1" s x='1'>
<persName>Schmuel ben Jehuda</persName>
<event when='1621-08-17' type="dateofdeath">
<desc/>
</event>
</person>
</listPerson>
</particDesc>
example – language Usage metadata:
<langUsage>

<language ident='he' usage='100'>Hebrew</language>
</langUsage>

With respect for the TEI Hackathon I have (just) set up a website with very general information how to harvest epidat records:
http://www.steinheim-institut.de/cgi-bin/epidat?info=howtoharvest (to be continued …)
Over and beyond that it would make no great difficulty to provide a zip file with the data available for the workshop.

'''Comments:'''
[[User:Thomas Kollatz|Thomas Kollatz]] 16:05, 1 July 2014 (CEST) The TEI spam filter seems to dislike the person-attribute s_x (middle-letter e) … rather prudish, isn't it

'''Discussion'''

What commonalities to you see? What seems interesting? Anything to add?

--[[User:Frederike Neuber|Frederike Neuber]] 23:21, 24 June 2014 (CEST)
Two (even if very different) projects, "Jewish Sepulchral Headstones DB" and "Rendering complex mark up", are dealing with visualization of spatial and temporal metadata.

Three (again very different) projects, "Visualization of intertextual TEI content", "Semantic Connections for Epigraphic Documents" and "Jewish Sepulchral Headstones DB", are dealing with semantic connection and modelling of content (even if not all of them say it explicitly in the description).

--[[User:Elli Bleeker|Elli Bleeker]] 16:25, 1 July 2014 (CEST)
Add to that the visualization of textual relations in the early Caribbean texts archive.

--[[User:Felix Lange| Felix Lange]] 16:30 4 July 2014 (CEST) - That's sounds pretty interesting, I'm on board. The text-analysis ("mining") part seems pretty tough, though. How exactly should the content of different inscriptions be compared? Do you think about general word-frequency-statistics, that can populate a Word-Cloud? Or do you plan text comparison that is "semantic" in a certain sense?

=== Core Builder ===
Another possible tool to work on: https://github.com/raffazizzi/coreBuilder
It provides a simple web interface to create stand-off markup. TEI files can be open into multiple ACE editors and the user can click on elements with xml:ids to create references.
The current version creates <app> elements containing <rdg>s with pointers to the selected elements. It should be easy enough to make the elements user configurable so that the Core Builder can be used to put together <linkGrp>s or <timeline>s.
The tool is written in CoffeScript with a [http://backbonejs.org/ Backbone] framework. --[[User:Raffaele.viglianti|Raffaele.viglianti]] 19:07, 16 June 2014 (CEST)

--[[User:Elli Bleeker|Elli Bleeker]] 16:23, 1 July 2014 (CEST) From the sound of it, I think I would like to work on this project. Some more detail would be great.

Here's a demo of the current version. It's got a few bugs but should show the basic functionality. Pick a couple of sources, then click on any element with xml:id to create a selection. Click add to save it to the "core". https://dl.dropboxusercontent.com/u/2443674/coreBuilder/index.html --[[User:Raffaele.viglianti|Raffaele.viglianti]] 02:31, 3 July 2014 (CEST)

DH2014Hackathon-Projects

2014-07-06T16:56:06Z

Rahtz: /* Basic framework for rendering a document and creating simple visualizations */

= DH2014 Hackathon Project Discussion Page =

== Let's Hack ==

A suggestion for how to proceed based on the range of proposals and the range of participants. The group is likely to be able to sustain 2 or at most 3 projects in the time frame allotted. Some suggestions; please modify, develop or otherwise shape to your liking!

=== Suggested setup using Git ===

There is a Git repository at https://github.com/TEIC/Hackathon which can be used for any group during the Hackathon. Sebastian Rahtz can add people to the TEI group on request so that they have write access. You can use any Git client, obviously. If you don't have a client setup
already and are on a Mac, you'll find https://mac.github.com/ easy to set up and use. If you possibly can, get your account and setup ready before the meet.

This repository is synchronized with a web server at http://tei.it.ox.ac.uk/Hackathon/ every minute. This web server has a CORS setup, which should allow cross-site scripting to work for any
group working with JSON or other Ajax technique.

To test this, clone the Git repository on your local laptop and open the file map/maptest.html in your browser. It should read JSON data from
http://tei.it.ox.ac.uk/Hackathon/map/objects.json and display it on a map. If you add more JSON data files to the repository, and push them up to Github, they should appear on the web server quite quickly; similarly this can be used to "publish" HTML.

Sebastian will be available during the Hackathon to wrangle the web server as needed.

=== ODD visualizer ===

A group might try to put together a plan and start to code up an ODD visualizer. ODD is a literate programming language for XML schemas written by the TEI, and which is used to define the TEI schema. An ODD visualizer might be a component of an ODD customization tool such as the successor of Roma, and could provide information to a user about what modules they have included in their TEI schema, or what modification they have made.

The group should start by discussing what to visualize, perhaps including some TEI users who has experience in customization.

'''Resources:''' About ODD [http://www.tei-c.org/Support/Learn/odds.xml Getting Started with P5 ODDs], [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/USE.html Guidelines Chapter 23: Using the TEI] and a look at [http://www.tei-c.org/Roma/ Roma], the tool that is currently in use for generating TEI customizations.

--[[User:Elli Bleeker|Elli Bleeker]] 16:05, 4 July 2014 (CEST) I know of some digital edition projects that are a priori TEI compliant but have added their own custamizations if the TEI Guidelines did not offer a sufficient solution for the <nowiki>"challenge"</nowiki> posed by the text. I can imagine there are more projects that do so. Is that meant by <nowiki>"modification"</nowiki> of the TEI schema?
It seems the ODD visualizer might be a good addition to the authorial workflow as described below, if it offers the editors insight in their specific text encoding methods.

[[User:Elena Spadini|Elena Spadini]] 12:13, 5 July 2014 (CEST) (I'm not sure this is the right place for adding names to a project as Elli wrote us, but) I would like to work on it!

[[User:Raffaele.viglianti|Raffaele.viglianti]] 13:40, 6 July 2014 (CEST) I'd happily work on this

--[[User:Rahtz|Rahtz]] 17:50, 6 July 2014 (CEST) Elli - a modification is often simply specifying a subset of the TEI, ie removing elements you don't need. Visualizing just this relationship is itself quite useful; the proof of concept at http://tei.it.ox.ac.uk/Byzantium/ demonstrates a trivial example. In an ideal alternate work, the visualization would dynamic. Ie it would show a list of modules, and you could click on one to remove the elements in it, and that would trigger writing an ODD file.

=== Basic framework for rendering a document and creating simple visualizations ===

This project could be quite extensive, so the group should begin by selecting components that they can manage.

The proposed outcome is to be able to display (or at least mine) a document for salient features, and to produce output generic enough that it can be passed to either mapping or to other visualization software. Or perhaps to the NY Times Pourover js library. One possible way to to do this is to decide on a json data structure, as that is a popular format for visualization libraries.

--[[User:Frederike Neuber|Frederike Neuber]] 08:08, 3 July 2014 (CEST) Are you referring to a particular visualization software on which it might be useful to take a quick look before the hackathon?

--[[User:Elli Mylonas|Elli Mylonas]] 11:27, 4 July 2014 (CEST) Frederike has a good comment - are there suggestions? Google Maps is one idea. Leaflet, and D3 (more complex) are others. Thoughts?

--[[User:Rahtz|Rahtz]] 17:02, 6 July 2014 (CEST) I would suggest we limit ourselves for this project to Leaflet (mapping) and D3 (graphs) with its companion C3. Both have loads of examples and addons. Leaflet rather than Google Maps because it doesn't need API keys etc, and can use other tiles easily. The key thing here is to proof of concept - get a visualization up and running quickly, then tweak it. If its successful, recoding it later in another library is not so hard. Note, however, that we come up against cross-site scripting when we read JSON in an HTML file. See Setup section above.

I like the idea that we take some texts and a) isolate a set of features that can be extracted for looking at, b) work out what they look like in JSON, and c) practice visualizing them in some way. I have added an example XSLT script at https://github.com/TEIC/Hackathon/blob/master/visualization/teitojson.xsl which shows how you'd grab (in this case persName) elements from a TEI XML file and write a JSON file. Demo result at http://tei.it.ox.ac.uk/Hackathon/visualization/test.json

=== Develop the MS description framework ===

This was one of the proposed projects that got a lot of comments. It could be developed along the lines of the comments, and generalized a bit.

[[User:Alexander Czmiel|Alexander Czmiel]] 14:20, 4 July 2014 (CEST) Maybe I don't get it, but it seems to me this project has the same aims like "Basic framework for rendering a document". Anyway, rendering TEI documents is an imortant issue which has not been adressed enough in the past. Especially when looking on complex markup such as recommended by the Genetic Markup SIG.
There are already a few approaches which try to do exactly the same, we want to do here: build a generic framework to publish TEI documents online. There is eLaborate (http://elaborate.huygens.knaw.nl/) from Den Haag, xMod (http://www.cch.kcl.ac.uk/xmod/) from London, DENQ from Rome, and SADE (best/current version on Github by vronk: https://github.com/vronk/SADE) which we try to build in Berlin/Göttingen/Wien. To a certain point OMEKA (http://www.omeka.net/) could be used as well, I think. There are many more, I don't know of. So please don't let us start from the scratch with a new project.

--[[User:Elli Bleeker|Elli Bleeker]] 14:56, 4 July 2014 (CEST) I agree it would be pointless to start from scratch. But it might be worth considering to further develop one of the abovementioned approaches. I am not familiar with all of them, but most tend to fail once the textual genetics becomes more complex. The fact that many of the proposed projects in this Hackathon are aimed at the rendering of complex TEI mark up, suggests that this is one of the most important needs of textual scholars and that there is still no sufficient way to do so.

--[[User:Frederike Neuber|Frederike Neuber]] 19:27, 4 July 2014 (CEST) It seems we have all different understandings of the project's descriptions - I will tell you mine too: 
In my opinion the two project aim different results, even if the workflow will be partly the same. 
The "rendering complex markup.." aims to offer in a creative visualization of the extracted data, so this project will be about including visualization software which supports data visualization beyond lists and timelines. 
The "MS description.." aims (or at least it did in the beginning) to create a framework which is applicable to each TEI-document containing a <msDesc> part and includes both displaying the <msDesc> content (in an linear way, no tricky visualization) and search and browse functions. The scope of this project is to provide in the end a set of files which anyone can use to render a <msDesc> part. 
So far.. can somebody bring light into the darkness please? :)

[[User:Patrik Granholm|Patrik Granholm]] 23:35, 4 July 2014 (CEST) My initial proposal was to create a simple search and browsing interface for MS descriptions which would be general enough to be used by other similar projects. But perhaps it is too specific. An interface for TEI-files in general would probably be more useful. The idea is that everything should be well documented so that people with limited programming skills would be able to modify the code to suit their needs. It would be more like an eXist template than a finished product.

[[User:Elena Spadini|Elena Spadini]] 12:08, 5 July 2014 (CEST) I don't think that it is too specific and an interface for TEI files in general is probably too wide for one day. For sure there are a lot of projects flourishing in this way (not eLaborate that is at a certain point TEI compliant but not at all TEI based), as everyone using TEI deals with the problems and find more or less home made solutions. But if during the Hackathon something can be started and finished, it would be a really good result!

--[[User:Frederike Neuber|Frederike Neuber]] 15:55, 5 July 2014 (CEST) Maybe we could decide whether we want to render the metadata or the text. I think some templates for rendering the <teiHeader> with focusing on search options (searching for certain fields, combining them, faceted search) would be nice. 
Can someone provide some XML files to work with?

[[User:Patrik Granholm|Patrik Granholm]] 08:55, 6 July 2014 (CEST) I have a few preliminary MS descriptions from our cataloguing project, and quite a large collection of MS descriptions from other projects which we could work with.

=== Discussing, working out and documenting best practices for an authoring workflow ===

Projects that last for many years, have many people working on them, and comprise large amounts of material need to ensure that work is being done efficiently, produce accurate output, and move files through transformations and validations. Good workflows can be enhanced by both tools and best practices. The outcome of this project could be a document with explanation and examples of authoring/encoding/proofreading/version control workflows with a focus on software tools.

--[[User:Elli Bleeker|Elli Bleeker]] 15:22, 4 July 2014 (CEST) Would we aim at enhancing the workflow of existing projects or suggest best practices for future projects? It would be very interesting to see whether it is possible to distinguish a best practice for an authoring workflow. Normally projects that run for many years and started <nowiki>"back in the days"</nowiki> have developed their own ad hoc workflow. They happily admit to have done things differently witht the knowledge of today. Of course the workflow depends upon the people working on it (trained editors, volunteers through crowd-sourcing...).
Perhaps the outcome would be several different workflows, depending on the type of material, the objectives of the project and the people collaborating on it.

== Participants ==

* [http://mith.umd.edu/people/person/raffaele-viglianti/ Raffaele Viglianti], University of Maryland
* [http://www.patrikgranholm.com Patrik Granholm], Uppsala University Library: [http://www.manuscripta.se Greek Manuscripts in Sweden. A Digitization and Cataloguing Project]
* [http://online.uni-graz.at/kfu_online/visitenkarte.show_vcard?pPersonenId=9570FBD84B50B383&pPersonenGruppe=3 Frederike Neuber], DiXiT - research fellow at Graz University - Austrian Centre for Digital Humanities
* Felix Lange, Academy of Sciences and Literature | Mainz, Project IBR (http://www.spatialhumanities.de)
* Emmanuelle Morlock, CNRS, HISoMA Laboratory (Histoire et Sources des mondes antiques / History and Origins of the Antique World)
* [https://www.uantwerpen.be/en/staff/elli-bleeker/ Elli Bleeker], PhD student in Digital Humanities at Antwerp University; research fellow at DiXiT
* Magdalena Turska, University of Oxford
* Nick Laiacona, Performant Software Solutions LLC www.performantsoftware.com
* Elizabeth Maddock Dillon, Professor of English and CoDirector of NULab for Texts, Maps, and Networks, Northeastern University, Boston, MA USA
* [http://steinheim-institut.de/wiki/index.php/Mitarbeiter:Thomas_Kollatz Thomas Kollatz], Steinheim-Institute for German-Jewish History: [http://steinheim-institut.de/cgi-bin/epidat epidat]
* Elena Spadini, Huygens Ing

* Sebastian Rahtz, University of Oxford
* James Cummings, University of Oxford
* [http://www.i-d-e.de/mitglieder/alexander-czmiel Alex Czmiel], Berlin-Brandenburg Academy of Sciences and Humanities
* Hugh Cayless, Duke University
* Elli Mylonas, Brown University

== Procedure ==

We will be using the wiki as a place for comments and discussion. The projects each participant proposed are all listed below. Ideally, the hackathon will be focussed around one or two projects that are useful to everyone. The participants are all experienced with TEI in various capacities, but they are not all skilled programmers. The hackathon would be a success if the outcome of the one day event was e a good start on one or two useful pieces of TEI related software. In order to achieve this, we should collectively decide on projects that are interesting, useful, generalizable, and do-able! We should also try to capitalize on everyone's skill set, and try to plan the event in such a way that we can all contribute to something.

You are all welcome to introduce yourselves, by adding a description of a few sentences to the list of participants above. And please, edit, correct and comment on the projects. We are also inviting the TEI Council and Board and other interested parties to look in on the discussions.

== Proposed Projects ==

=== Mormon City Planning: ===
when early Mormonism ventured from Kirtland, Ohio, into Missouri, their prophet Joseph Smith Jr provided a revelation for the plat (city layout) of the new Zion (http://urbanplanning.library.cornell.edu/DOCS/smith.htm; http://zomarah.files.wordpress.com/2010/10/firstplatofzion.png), which was subsequently applied in the settlement of Far West, Missouri, for which two plats exist, one on sheepskin (https://www.lds.org/bc/content/shared/content/images/gospel-library/manual/32502/15-02 b.gif) in private possession and one on paper at BYU University (there is no online copy of this, but I have obtained a digital copy from BYU with their permission); however these plats were not only used to sketch out the city, but also to assign lots to settlers, and thus show secondary markup in pencil to allocate houses, redraw lot boundaries, etc; (http://zomarah.files.wordpress.com/2010/10/platoffarwestbig.png)

'''Comments:'''
* A clarification: What would the project strive to accomplish? Is this a visualization? georeferencing based on markup?
* [[User:Thomas Kollatz|Thomas Kollatz]] 11:57, 1 July 2014 (CEST) https://www.lds.org/bc/content/shared/content/images/gospel-library/manual/32502/15-02 error 404 - not found; maybe visualization: text-information encoded in TEI related to city layout ("plat") in SVG ?

=== ODD Customization visualizer ===
A web-based tool to visualize any ODD customization against TEI-all. This could be useful when working on a customization (with Roma, or manually) to quickly and visually check that the ODD is still TEI-conformant and see how it diverges from the standard.
I started working on a basic D3 visualization a couple of years ago, but haven't really touched the code since:https://github.com/raffazizzi/ODDViz I only restructured the repository a bit before sending this proposal.

'''Comments'''
A simple demo: https://dl.dropboxusercontent.com/u/2443674/ODDViz/index.html --[[User:Raffaele.viglianti|Raffaele.viglianti]] 03:02, 3 July 2014 (CEST)

=== ACE-based Web editor ===

MITH, at the University of Maryland has been working on an ACE-based web editor able to validate tei-all files in the browser and provide ODD-based contextual help (e.g. suggesting valid options when entering a new element).
The grant that funded this work is now over, but there's plenty more to do. This is the GitHub repository: https://github.com/umd-mith/angles

'''Comments:'''

=== MS Description Display Framework ===
To create a simple web interface which would provide basic functionalities like browsing, searching and displaying TEI-files containing manuscript descriptions. The interface could be built using a Ubuntu server with [http://nginx.org nginx], and [http://exist-db.org eXist-db] following the setup guide and scripts provided by [https://github.com/grantmacken/nginx-eXist-ubuntu Grant Macken]. I have already made some preliminary work on an eXist-db web interface and posted the code in our [https://github.com/manuscripta GitHub repository]. This could be used as a starting point for further development. A possible goal for the hackathon could be to create an advanced search form in XQuery which would display snippets of the descriptions in the search results using the transform function with our XSL stylesheet, with links to the full description. All of the code, with detailed documentation, would be made public on GitHub for others to reuse and modify for their own projects. I think this would be beneficial to the TEI community at large, and especially to other cataloguing projects.

'''Comments:'''

* I believe this would be really useful project, especially if we build it not only having this particular purpose of MS descriptions in mind, but something more general, so other users would potentially swap only source files and stylesheets and would have a basic working website. [[User:Magdalena Turska|Magdalena Turska]] 11:00, 23 June 2014 (CEST)
* me too – more general features almost every project will need after swapping source files and stylesheets: navigation to next page/object ; or: navigation to next entry/object in chronological order, full text search everywhere resp in particular div's (type="edition") etc. [[User:Thomas Kollatz|Thomas Kollatz]] 12:09, 1 July 2014 (CEST)
* I am definitely open to creating a more general display framework in eXist. Perhaps we could make use of Joe Wicentowski’s [http://digital.humanities.ox.ac.uk/dhoxss/2011/presentations/Wicentowski-XMLDatabases-materials.zip Punch eXist tutorial] from DHOxSS 2011. [[User:Patrik Granholm|Patrik Granholm]] 11:16, 2 July 2014 (CEST)

=== Medieval Text Edition ===

<strike>
Project isn't advanced enough to suggest concrete task, but the topic of interest is focussed around a digital scholarly edition of a medieval text (with corresponding images) encoded in XML/TEI. The edition will be enriched with palaeographical and codicological information (in both <text> and <teiHeader>) and the results can be visualized in a way which hopefully goes beyond the sometimes not very enlightening listing of data.</strike>

'''Comments:'''
Even now my project is not advanced enough to be used for the hackathon. I will join the discussions on the other projects. --[[User:Frederike Neuber|Frederike Neuber]] 22:05, 24 June 2014 (CEST)

=== Semantic Connections for Epigraphic Documents ===
I am currently working with epidoc documents in the context of the Project IBR. These documents, epigraphical editions from the catalogue "German Inscriptions Online" (inschriften.net), are (1) to be transformed into RDFtriples for semantic connection and for a finegrained quantificational analysis in a Triple Store, (2) XSLT transformed into HTMLDocuments for further annotation in the semantic annotator "Pundit"(thepund.it). I could surely contribute a programming task based on this points, but would also be happy to participate in another task, preferably based on "adding a TEI mode to a web editor".

'''Comments:'''

--[[User:Frederike Neuber|Frederike Neuber]] 23:02, 24 June 2014 (CEST) Who is responsible for this project and can provide further information?
I would be very interested in joining this project even if I can't offer material and even if I do not understand one step: how can you transform an epidoc document into RDF triples? Do you mean you generate RDF from the annotated entities (extracting them?)? And how do you do it, are there tools or software to support it?

[[User:Thomas Kollatz|Thomas Kollatz]] 12:12, 1 July 2014 (CEST) The [http://www.tei-c.org/oxgarage/ oxgarage] magic box contains already a tool converting TEI2RDF, if so – we should try it out and evaluate it if not - let's develop it …

[[User:Felix Lange|Felix Lange]]14:56, 4 July 2014 (CEST) Thomas Kollatz is right, this tool is quite mature by now, making a new development from scratch pointless. But is there a programmatic (e.g. ReST) interface to the converter? If not, let's do it! @Frederike, some further project informations can be found at www.spatialhumanities.de/ibr, our project website.

=== Zotero ===
Some TEI encoding project may need to use a "master bibliography" to group together all the bibliographic references that are used in a given text or collection of texts. Using the "masterfile" option in Oxygen give the user a convenient way of pointing to a reference without having to encode a ref each time it is used in a text or in a specific bibliographic section.
<pre>
<bibl type="fromStone">
<ptr target="#Breal1878"/>
<citedRange>15</citedRange>
</bibl>
</pre>

The bibliography can be inserted in a <back/> element with xinclude. But the question is how to use Zotero to create this file, update it and synchonize it with the biblographic masterfile.
Though incomplete, the workflow I use works like that :
* the entering of the bibliographic entries is done with zotero, in a group library
* the zotero database is then exported in xml using the "bibliontology_rdf" format (the TEI export format being to restrictive in its formatting choices : e.g. does'nt include "short titles" which are a requisite in epigraphy
* the bibliontology rdf is converted in TEI through XSLT in Oxygen (modifying existing xslt :https://github.com/paregorios/Zotero-RDF-to-TEI-XML)
* If the user wants to add a new reference in the masterbibliography or correct an entry, he or she has to do go to zotero and follow the whole workflow of export - tranform process. But the user might not have the user right to do so. And of course, there are some potential conflicting issues.

How to improve that workflow ? use a version control system like git or subversion ? or adding/modifying an entry in xml / tei and then updating the zotero group library via api ?

'''Comments:'''
--[[User:Elli Bleeker|Elli Bleeker]] 15:29, 1 July 2014 (CEST) It seems that working with subversion would improve the workflow a lot and at least illiminate the risk of conflicting issues. Of course users should have the right to work in the (seperate) xml file of the bibliographic masterfile and add/change references. Once completed, the xml file can be exported to Zotero. In short, this would mean a reverse of the current workflow.

=== Migrating value lists form CSS frameworks to ODD ===

The author mode of the Oxygen editor can be customized with custom css functions. A part from the function providing a more user-friendly and tag free visualization of the tei content, one of the fuction allow the user to edit attributes or simple elements values using combo boxes or check boxes. The "form controls" can display values collected from an xml schema. But these values can also be just in the oxygen css. This may be used in a workflow to test some choices before integrating them in a more consistent and persistant way in the ODD (then exported in the schema).

This could be useful in case you have user that may be ok to change the values in the css code but would be relunctant to get involved with the ODD editing / schema generation process.
cf. http://www.oxygenxml.com/doc/ug-editor/concepts/combo-box-editor.html#combo-box-editor

'''Comments:'''

--[[User:Raffaele.viglianti|Raffaele.viglianti]] 19:20, 16 June 2014 (CEST) This is interesting, would like to work on it. I would suggest to make it less tied to Oxygen and think in terms of CSS to ODD, for example to limit attribute values (e.g. hi[rend=italic])

[[User:Elena Spadini|Elena Spadini]] 00:13, 24 June 2014 (CEST) I'm not well-exeperienced with the author mode in oXygen and its customizations, but I would like to explore it working on this project.

=== Visualization of intertextual TEI content ===
[UPDATED on June 24th]

The focus is on the possibilities offered by TEI XML for encoding intertextuality. The case study concerns the personal library of an author and a digital edition of his work. The objective is to encode the material in such a way that the intertextual relations between the literary work and its external sources is visualized.

These -sometimes subtle- intertextual relationships provide insight into the nature of writing, all the more since the genesis of the literary work itself is already encoded in the edition (i.e. adds, dels, etc.). The envisioned result enables a user to study the writing process in detail as well as on a larger scale.

Material:
* detailed XML TEI transcription of the literary work concerned
* high quality digital facsimiles of the author's personal '''extant''' library
* rough transcriptions of the library books (based on OCR)

'''Comments:'''

* Clarification: is the project about the visualization? the relationships? More detail would be great.
*
--[[User:Elli Bleeker|Elli Bleeker]] 15:46, 1 July 2014 (CEST) The idea is to log the complete <nowiki>"path"</nowiki> of a citation: from a phrase underlined in a library book to the incorporation of that phrase in the author's work.
Currently, the intertextual references are encoded with [ref] tag in the XML TEI transcription of the literary work. The [ref]s refer to another xml file containing the transcriptions of the personal library. This file consists of [div]s, that contain anything from a complete library book to a small section (paragraph, phrase) from a library book.

The visualization of the intertextual relations comes in a later stage when transforming the documents. I wonder whether it is possible to change or improve this encoding.

=== Rendering Complex Markup ===
Rendering complex markup in an innovative and playful way: reconstructing & visualizing author’s
geographical position by the dates of sending of his letters (taking uncertainty into account)

'''Comments:'''

[[User:Magdalena Turska|Magdalena Turska]] 12:36, 12 June 2014 (CEST)

Starting with a list of letters that have a place and date of sending the idea would be to present map overview of the author's journeys.
See the simple Google Map at https://mapsengine.google.com/map/edit?mid=z3q4AefiR7Us.kf1fVBHlu8qE

Fist ideas re visualisation:
* places color-coded with color getting darker to represent 'later' places
* similarly shaded lines along the routes between places
* animation with slider to show circle moving along the routes, size of the circle getting bigger with the uncertainty

Input data:
each letter has assigned place name and 1+ time intervals (notBefore to not After)

--[[User:Frederike Neuber|Frederike Neuber]] 22:25, 24 June 2014 (CEST)
Would it be a problem to work on different material? @TEI-experts
I would like to visualize the provenance of medieval manuscripts on a map, so even if I do not work with letters, the task is partly the same (extracting date and time from the <teiHeader> and visualizing it on a map). Then our scopes separate: Magdalena wants to reconstruct the journey, I want to visualize the chronology of different mss on one map.

[[User:Thomas Kollatz|Thomas Kollatz]] 15:56, 1 July 2014 (CEST)
I agree with [[User:Frederike Neuber|Frederike Neuber]]: the task is the same in all projects, where a spatio-temporal visualization makes sense: Extract date and time from header - and visualize the chronology of date/time and place on a map and/or timeline
/TEI/teiHeader/fileDesc/sourceDesc/msDesc/history/origin

=== Adding a TEI mode to a web editor ===
Title says it all!

'''Comments:'''

--[[User:Raffaele.viglianti|Raffaele.viglianti]] 19:20, 16 June 2014 (CEST) How does the [http://wiki.tei-c.org/index.php/DH2014Hackathon-Projects#ACE-based_Web_editor Angles] proposal above sound?

=== Juxta Script support ===
Adding support for Bengali text to Juxta Commons

'''Comments:'''
* This is fairly narrow.
[[User:Thomas Kollatz|Thomas Kollatz]] 15:57, 1 July 2014 (CEST) If Bengali then Hebrew (Arabic … right-to-left), please

=== Visualization ===
The archive of early Caribbean texts and images is a fairly large project which will be heavily encoded (and a portion of texts will be encoded by July). I'd like to explore ways of using the TEI to visualize relations between and among texts and elements of texts.

'''Comments:'''

--[[User:Elli Bleeker|Elli Bleeker]] 16:19, 1 July 2014 (CEST) What is the status of this project? I am also interested in finding ways to visualize relations between texts, perhaps there are similarities?

=== Jewish Sepulchral Headstones DB ===

Given that all headstones can be clearly located,
and about 20.000 (of total 26.000) inscriptions are dated,
and to a large extend can be distinguished by gender,
and also by language usage (hebrew, german, german in Hebrew letters, …),
they lend themselves to mining the epidat corpus for specific data facets and try to visualize the results "in an innovative and playful way".
#A challenging research questions could be the search for and visualization of the differences in word usage and specific idiomatic
## between different locations,
## within different periods (based on one or several locations),
## between inscriptions for men and inscriptions for women,
## between hebrew and non-hebrew inscriptions …
#Even more challenging is the search for inscriptions with very similar text coverage. These are quite difficult to discover by a simple full text search. The inscriptions are usually rather short, and the filter to develop has to consider the differentiating elements – usually names and dates – in order to determine, whether two text are identical or not.

All necessary information to answer this questions is contained in the metadata <teiHeader> and data <text> of each single record.
example – spatial and temporal metadata (date, country/region code, geo-coordinates, Thesaurus of Getty Names or OSM ID)
<history>
<origin>
<date notBefore='1621-08-17'>1621-08-17</date>
<country type="ISO_3166" key="XA-DE-HH">
Germany
<region>Hamburg</region>
</country>
<settlement type='city' key='tgn:7012310'>
Hamburg-Altona, Königstraße
<geogName>
Jüdischer Friedhof
<geo decls="#WGS">53.549373 9.950545</geo>
</geogName>
</settlement>
</origin>
</history>
example – gender-specific metadata (given according to ISO 5218:2004)
<particDesc>
<listPerson>
<person xml:id="hha-3361-1" s x='1'>
<persName>Schmuel ben Jehuda</persName>
<event when='1621-08-17' type="dateofdeath">
<desc/>
</event>
</person>
</listPerson>
</particDesc>
example – language Usage metadata:
<langUsage>

<language ident='he' usage='100'>Hebrew</language>
</langUsage>

With respect for the TEI Hackathon I have (just) set up a website with very general information how to harvest epidat records:
http://www.steinheim-institut.de/cgi-bin/epidat?info=howtoharvest (to be continued …)
Over and beyond that it would make no great difficulty to provide a zip file with the data available for the workshop.

'''Comments:'''
[[User:Thomas Kollatz|Thomas Kollatz]] 16:05, 1 July 2014 (CEST) The TEI spam filter seems to dislike the person-attribute s_x (middle-letter e) … rather prudish, isn't it

'''Discussion'''

What commonalities to you see? What seems interesting? Anything to add?

--[[User:Frederike Neuber|Frederike Neuber]] 23:21, 24 June 2014 (CEST)
Two (even if very different) projects, "Jewish Sepulchral Headstones DB" and "Rendering complex mark up", are dealing with visualization of spatial and temporal metadata.

Three (again very different) projects, "Visualization of intertextual TEI content", "Semantic Connections for Epigraphic Documents" and "Jewish Sepulchral Headstones DB", are dealing with semantic connection and modelling of content (even if not all of them say it explicitly in the description).

--[[User:Elli Bleeker|Elli Bleeker]] 16:25, 1 July 2014 (CEST)
Add to that the visualization of textual relations in the early Caribbean texts archive.

--[[User:Felix Lange| Felix Lange]] 16:30 4 July 2014 (CEST) - That's sounds pretty interesting, I'm on board. The text-analysis ("mining") part seems pretty tough, though. How exactly should the content of different inscriptions be compared? Do you think about general word-frequency-statistics, that can populate a Word-Cloud? Or do you plan text comparison that is "semantic" in a certain sense?

=== Core Builder ===
Another possible tool to work on: https://github.com/raffazizzi/coreBuilder
It provides a simple web interface to create stand-off markup. TEI files can be open into multiple ACE editors and the user can click on elements with xml:ids to create references.
The current version creates <app> elements containing <rdg>s with pointers to the selected elements. It should be easy enough to make the elements user configurable so that the Core Builder can be used to put together <linkGrp>s or <timeline>s.
The tool is written in CoffeScript with a [http://backbonejs.org/ Backbone] framework. --[[User:Raffaele.viglianti|Raffaele.viglianti]] 19:07, 16 June 2014 (CEST)

--[[User:Elli Bleeker|Elli Bleeker]] 16:23, 1 July 2014 (CEST) From the sound of it, I think I would like to work on this project. Some more detail would be great.

Here's a demo of the current version. It's got a few bugs but should show the basic functionality. Pick a couple of sources, then click on any element with xml:id to create a selection. Click add to save it to the "core". https://dl.dropboxusercontent.com/u/2443674/coreBuilder/index.html --[[User:Raffaele.viglianti|Raffaele.viglianti]] 02:31, 3 July 2014 (CEST)

User:Rahtz

2014-07-06T15:52:56Z

Rahtz: Created page with "I'm Sebastian Rahtz, currently director of academic IT at IT Services in the University of Oxford. I've been doing a lot of TEI since since about 2000, and you'll find my spoor a..."

I'm Sebastian Rahtz, currently director of academic IT at IT Services in the University of Oxford. I've been doing a lot of TEI
since since about 2000, and you'll find my spoor all over the TEI Sourceforge and Github projects.

[[Category:Users]]

DH2014Hackathon-Projects

2014-07-06T15:50:51Z

Rahtz: /* ODD visualizer */

= DH2014 Hackathon Project Discussion Page =

== Let's Hack ==

A suggestion for how to proceed based on the range of proposals and the range of participants. The group is likely to be able to sustain 2 or at most 3 projects in the time frame allotted. Some suggestions; please modify, develop or otherwise shape to your liking!

=== Suggested setup using Git ===

There is a Git repository at https://github.com/TEIC/Hackathon which can be used for any group during the Hackathon. Sebastian Rahtz can add people to the TEI group on request so that they have write access. You can use any Git client, obviously. If you don't have a client setup
already and are on a Mac, you'll find https://mac.github.com/ easy to set up and use. If you possibly can, get your account and setup ready before the meet.

This repository is synchronized with a web server at http://tei.it.ox.ac.uk/Hackathon/ every minute. This web server has a CORS setup, which should allow cross-site scripting to work for any
group working with JSON or other Ajax technique.

To test this, clone the Git repository on your local laptop and open the file map/maptest.html in your browser. It should read JSON data from
http://tei.it.ox.ac.uk/Hackathon/map/objects.json and display it on a map. If you add more JSON data files to the repository, and push them up to Github, they should appear on the web server quite quickly; similarly this can be used to "publish" HTML.

Sebastian will be available during the Hackathon to wrangle the web server as needed.

=== ODD visualizer ===

A group might try to put together a plan and start to code up an ODD visualizer. ODD is a literate programming language for XML schemas written by the TEI, and which is used to define the TEI schema. An ODD visualizer might be a component of an ODD customization tool such as the successor of Roma, and could provide information to a user about what modules they have included in their TEI schema, or what modification they have made.

The group should start by discussing what to visualize, perhaps including some TEI users who has experience in customization.

'''Resources:''' About ODD [http://www.tei-c.org/Support/Learn/odds.xml Getting Started with P5 ODDs], [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/USE.html Guidelines Chapter 23: Using the TEI] and a look at [http://www.tei-c.org/Roma/ Roma], the tool that is currently in use for generating TEI customizations.

--[[User:Elli Bleeker|Elli Bleeker]] 16:05, 4 July 2014 (CEST) I know of some digital edition projects that are a priori TEI compliant but have added their own custamizations if the TEI Guidelines did not offer a sufficient solution for the <nowiki>"challenge"</nowiki> posed by the text. I can imagine there are more projects that do so. Is that meant by <nowiki>"modification"</nowiki> of the TEI schema?
It seems the ODD visualizer might be a good addition to the authorial workflow as described below, if it offers the editors insight in their specific text encoding methods.

[[User:Elena Spadini|Elena Spadini]] 12:13, 5 July 2014 (CEST) (I'm not sure this is the right place for adding names to a project as Elli wrote us, but) I would like to work on it!

[[User:Raffaele.viglianti|Raffaele.viglianti]] 13:40, 6 July 2014 (CEST) I'd happily work on this

--[[User:Rahtz|Rahtz]] 17:50, 6 July 2014 (CEST) Elli - a modification is often simply specifying a subset of the TEI, ie removing elements you don't need. Visualizing just this relationship is itself quite useful; the proof of concept at http://tei.it.ox.ac.uk/Byzantium/ demonstrates a trivial example. In an ideal alternate work, the visualization would dynamic. Ie it would show a list of modules, and you could click on one to remove the elements in it, and that would trigger writing an ODD file.

=== Basic framework for rendering a document and creating simple visualizations ===

This project could be quite extensive, so the group should begin by selecting components that they can manage.

The proposed outcome is to be able to display (or at least mine) a document for salient features, and to produce output generic enough that it can be passed to either mapping or to other visualization software. Or perhaps to the NY Times Pourover js library. One possible way to to do this is to decide on a json data structure, as that is a popular format for visualization libraries.

--[[User:Frederike Neuber|Frederike Neuber]] 08:08, 3 July 2014 (CEST) Are you referring to a particular visualization software on which it might be useful to take a quick look before the hackathon?

--[[User:Elli Mylonas|Elli Mylonas]] 11:27, 4 July 2014 (CEST) Frederike has a good comment - are there suggestions? Google Maps is one idea. Leaflet, and D3 (more complex) are others. Thoughts?

--[[User:Rahtz|Rahtz]] 17:02, 6 July 2014 (CEST) I would suggest we limit ourselves for this project to Leaflet (mapping) and D3 (graphs) with its companion C3. Both have loads of examples and addons. Leaflet rather than Google Maps because it doesn't need API keys etc, and can use other tiles easily. The key thing here is to proof of concept - get a visualization up and running quickly, then tweak it. If its successful, recoding it later in another library is not so hard. Note, however, that we come up against cross-site scripting which we read JSON in an HTML file. See Setup section above.

=== Develop the MS description framework ===

This was one of the proposed projects that got a lot of comments. It could be developed along the lines of the comments, and generalized a bit.

[[User:Alexander Czmiel|Alexander Czmiel]] 14:20, 4 July 2014 (CEST) Maybe I don't get it, but it seems to me this project has the same aims like "Basic framework for rendering a document". Anyway, rendering TEI documents is an imortant issue which has not been adressed enough in the past. Especially when looking on complex markup such as recommended by the Genetic Markup SIG.
There are already a few approaches which try to do exactly the same, we want to do here: build a generic framework to publish TEI documents online. There is eLaborate (http://elaborate.huygens.knaw.nl/) from Den Haag, xMod (http://www.cch.kcl.ac.uk/xmod/) from London, DENQ from Rome, and SADE (best/current version on Github by vronk: https://github.com/vronk/SADE) which we try to build in Berlin/Göttingen/Wien. To a certain point OMEKA (http://www.omeka.net/) could be used as well, I think. There are many more, I don't know of. So please don't let us start from the scratch with a new project.

--[[User:Elli Bleeker|Elli Bleeker]] 14:56, 4 July 2014 (CEST) I agree it would be pointless to start from scratch. But it might be worth considering to further develop one of the abovementioned approaches. I am not familiar with all of them, but most tend to fail once the textual genetics becomes more complex. The fact that many of the proposed projects in this Hackathon are aimed at the rendering of complex TEI mark up, suggests that this is one of the most important needs of textual scholars and that there is still no sufficient way to do so.

--[[User:Frederike Neuber|Frederike Neuber]] 19:27, 4 July 2014 (CEST) It seems we have all different understandings of the project's descriptions - I will tell you mine too: 
In my opinion the two project aim different results, even if the workflow will be partly the same. 
The "rendering complex markup.." aims to offer in a creative visualization of the extracted data, so this project will be about including visualization software which supports data visualization beyond lists and timelines. 
The "MS description.." aims (or at least it did in the beginning) to create a framework which is applicable to each TEI-document containing a <msDesc> part and includes both displaying the <msDesc> content (in an linear way, no tricky visualization) and search and browse functions. The scope of this project is to provide in the end a set of files which anyone can use to render a <msDesc> part. 
So far.. can somebody bring light into the darkness please? :)

[[User:Patrik Granholm|Patrik Granholm]] 23:35, 4 July 2014 (CEST) My initial proposal was to create a simple search and browsing interface for MS descriptions which would be general enough to be used by other similar projects. But perhaps it is too specific. An interface for TEI-files in general would probably be more useful. The idea is that everything should be well documented so that people with limited programming skills would be able to modify the code to suit their needs. It would be more like an eXist template than a finished product.

[[User:Elena Spadini|Elena Spadini]] 12:08, 5 July 2014 (CEST) I don't think that it is too specific and an interface for TEI files in general is probably too wide for one day. For sure there are a lot of projects flourishing in this way (not eLaborate that is at a certain point TEI compliant but not at all TEI based), as everyone using TEI deals with the problems and find more or less home made solutions. But if during the Hackathon something can be started and finished, it would be a really good result!

--[[User:Frederike Neuber|Frederike Neuber]] 15:55, 5 July 2014 (CEST) Maybe we could decide whether we want to render the metadata or the text. I think some templates for rendering the <teiHeader> with focusing on search options (searching for certain fields, combining them, faceted search) would be nice. 
Can someone provide some XML files to work with?

[[User:Patrik Granholm|Patrik Granholm]] 08:55, 6 July 2014 (CEST) I have a few preliminary MS descriptions from our cataloguing project, and quite a large collection of MS descriptions from other projects which we could work with.

=== Discussing, working out and documenting best practices for an authoring workflow ===

Projects that last for many years, have many people working on them, and comprise large amounts of material need to ensure that work is being done efficiently, produce accurate output, and move files through transformations and validations. Good workflows can be enhanced by both tools and best practices. The outcome of this project could be a document with explanation and examples of authoring/encoding/proofreading/version control workflows with a focus on software tools.

--[[User:Elli Bleeker|Elli Bleeker]] 15:22, 4 July 2014 (CEST) Would we aim at enhancing the workflow of existing projects or suggest best practices for future projects? It would be very interesting to see whether it is possible to distinguish a best practice for an authoring workflow. Normally projects that run for many years and started <nowiki>"back in the days"</nowiki> have developed their own ad hoc workflow. They happily admit to have done things differently witht the knowledge of today. Of course the workflow depends upon the people working on it (trained editors, volunteers through crowd-sourcing...).
Perhaps the outcome would be several different workflows, depending on the type of material, the objectives of the project and the people collaborating on it.

== Participants ==

* [http://mith.umd.edu/people/person/raffaele-viglianti/ Raffaele Viglianti], University of Maryland
* [http://www.patrikgranholm.com Patrik Granholm], Uppsala University Library: [http://www.manuscripta.se Greek Manuscripts in Sweden. A Digitization and Cataloguing Project]
* [http://online.uni-graz.at/kfu_online/visitenkarte.show_vcard?pPersonenId=9570FBD84B50B383&pPersonenGruppe=3 Frederike Neuber], DiXiT - research fellow at Graz University - Austrian Centre for Digital Humanities
* Felix Lange, Academy of Sciences and Literature | Mainz, Project IBR (http://www.spatialhumanities.de)
* Emmanuelle Morlock, CNRS, HISoMA Laboratory (Histoire et Sources des mondes antiques / History and Origins of the Antique World)
* [https://www.uantwerpen.be/en/staff/elli-bleeker/ Elli Bleeker], PhD student in Digital Humanities at Antwerp University; research fellow at DiXiT
* Magdalena Turska, University of Oxford
* Nick Laiacona, Performant Software Solutions LLC www.performantsoftware.com
* Elizabeth Maddock Dillon, Professor of English and CoDirector of NULab for Texts, Maps, and Networks, Northeastern University, Boston, MA USA
* [http://steinheim-institut.de/wiki/index.php/Mitarbeiter:Thomas_Kollatz Thomas Kollatz], Steinheim-Institute for German-Jewish History: [http://steinheim-institut.de/cgi-bin/epidat epidat]
* Elena Spadini, Huygens Ing

* Sebastian Rahtz, University of Oxford
* James Cummings, University of Oxford
* [http://www.i-d-e.de/mitglieder/alexander-czmiel Alex Czmiel], Berlin-Brandenburg Academy of Sciences and Humanities
* Hugh Cayless, Duke University
* Elli Mylonas, Brown University

== Procedure ==

We will be using the wiki as a place for comments and discussion. The projects each participant proposed are all listed below. Ideally, the hackathon will be focussed around one or two projects that are useful to everyone. The participants are all experienced with TEI in various capacities, but they are not all skilled programmers. The hackathon would be a success if the outcome of the one day event was e a good start on one or two useful pieces of TEI related software. In order to achieve this, we should collectively decide on projects that are interesting, useful, generalizable, and do-able! We should also try to capitalize on everyone's skill set, and try to plan the event in such a way that we can all contribute to something.

You are all welcome to introduce yourselves, by adding a description of a few sentences to the list of participants above. And please, edit, correct and comment on the projects. We are also inviting the TEI Council and Board and other interested parties to look in on the discussions.

== Proposed Projects ==

=== Mormon City Planning: ===
when early Mormonism ventured from Kirtland, Ohio, into Missouri, their prophet Joseph Smith Jr provided a revelation for the plat (city layout) of the new Zion (http://urbanplanning.library.cornell.edu/DOCS/smith.htm; http://zomarah.files.wordpress.com/2010/10/firstplatofzion.png), which was subsequently applied in the settlement of Far West, Missouri, for which two plats exist, one on sheepskin (https://www.lds.org/bc/content/shared/content/images/gospel-library/manual/32502/15-02 b.gif) in private possession and one on paper at BYU University (there is no online copy of this, but I have obtained a digital copy from BYU with their permission); however these plats were not only used to sketch out the city, but also to assign lots to settlers, and thus show secondary markup in pencil to allocate houses, redraw lot boundaries, etc; (http://zomarah.files.wordpress.com/2010/10/platoffarwestbig.png)

'''Comments:'''
* A clarification: What would the project strive to accomplish? Is this a visualization? georeferencing based on markup?
* [[User:Thomas Kollatz|Thomas Kollatz]] 11:57, 1 July 2014 (CEST) https://www.lds.org/bc/content/shared/content/images/gospel-library/manual/32502/15-02 error 404 - not found; maybe visualization: text-information encoded in TEI related to city layout ("plat") in SVG ?

=== ODD Customization visualizer ===
A web-based tool to visualize any ODD customization against TEI-all. This could be useful when working on a customization (with Roma, or manually) to quickly and visually check that the ODD is still TEI-conformant and see how it diverges from the standard.
I started working on a basic D3 visualization a couple of years ago, but haven't really touched the code since:https://github.com/raffazizzi/ODDViz I only restructured the repository a bit before sending this proposal.

'''Comments'''
A simple demo: https://dl.dropboxusercontent.com/u/2443674/ODDViz/index.html --[[User:Raffaele.viglianti|Raffaele.viglianti]] 03:02, 3 July 2014 (CEST)

=== ACE-based Web editor ===

MITH, at the University of Maryland has been working on an ACE-based web editor able to validate tei-all files in the browser and provide ODD-based contextual help (e.g. suggesting valid options when entering a new element).
The grant that funded this work is now over, but there's plenty more to do. This is the GitHub repository: https://github.com/umd-mith/angles

'''Comments:'''

=== MS Description Display Framework ===
To create a simple web interface which would provide basic functionalities like browsing, searching and displaying TEI-files containing manuscript descriptions. The interface could be built using a Ubuntu server with [http://nginx.org nginx], and [http://exist-db.org eXist-db] following the setup guide and scripts provided by [https://github.com/grantmacken/nginx-eXist-ubuntu Grant Macken]. I have already made some preliminary work on an eXist-db web interface and posted the code in our [https://github.com/manuscripta GitHub repository]. This could be used as a starting point for further development. A possible goal for the hackathon could be to create an advanced search form in XQuery which would display snippets of the descriptions in the search results using the transform function with our XSL stylesheet, with links to the full description. All of the code, with detailed documentation, would be made public on GitHub for others to reuse and modify for their own projects. I think this would be beneficial to the TEI community at large, and especially to other cataloguing projects.

'''Comments:'''

* I believe this would be really useful project, especially if we build it not only having this particular purpose of MS descriptions in mind, but something more general, so other users would potentially swap only source files and stylesheets and would have a basic working website. [[User:Magdalena Turska|Magdalena Turska]] 11:00, 23 June 2014 (CEST)
* me too – more general features almost every project will need after swapping source files and stylesheets: navigation to next page/object ; or: navigation to next entry/object in chronological order, full text search everywhere resp in particular div's (type="edition") etc. [[User:Thomas Kollatz|Thomas Kollatz]] 12:09, 1 July 2014 (CEST)
* I am definitely open to creating a more general display framework in eXist. Perhaps we could make use of Joe Wicentowski’s [http://digital.humanities.ox.ac.uk/dhoxss/2011/presentations/Wicentowski-XMLDatabases-materials.zip Punch eXist tutorial] from DHOxSS 2011. [[User:Patrik Granholm|Patrik Granholm]] 11:16, 2 July 2014 (CEST)

=== Medieval Text Edition ===

<strike>
Project isn't advanced enough to suggest concrete task, but the topic of interest is focussed around a digital scholarly edition of a medieval text (with corresponding images) encoded in XML/TEI. The edition will be enriched with palaeographical and codicological information (in both <text> and <teiHeader>) and the results can be visualized in a way which hopefully goes beyond the sometimes not very enlightening listing of data.</strike>

'''Comments:'''
Even now my project is not advanced enough to be used for the hackathon. I will join the discussions on the other projects. --[[User:Frederike Neuber|Frederike Neuber]] 22:05, 24 June 2014 (CEST)

=== Semantic Connections for Epigraphic Documents ===
I am currently working with epidoc documents in the context of the Project IBR. These documents, epigraphical editions from the catalogue "German Inscriptions Online" (inschriften.net), are (1) to be transformed into RDFtriples for semantic connection and for a finegrained quantificational analysis in a Triple Store, (2) XSLT transformed into HTMLDocuments for further annotation in the semantic annotator "Pundit"(thepund.it). I could surely contribute a programming task based on this points, but would also be happy to participate in another task, preferably based on "adding a TEI mode to a web editor".

'''Comments:'''

--[[User:Frederike Neuber|Frederike Neuber]] 23:02, 24 June 2014 (CEST) Who is responsible for this project and can provide further information?
I would be very interested in joining this project even if I can't offer material and even if I do not understand one step: how can you transform an epidoc document into RDF triples? Do you mean you generate RDF from the annotated entities (extracting them?)? And how do you do it, are there tools or software to support it?

[[User:Thomas Kollatz|Thomas Kollatz]] 12:12, 1 July 2014 (CEST) The [http://www.tei-c.org/oxgarage/ oxgarage] magic box contains already a tool converting TEI2RDF, if so – we should try it out and evaluate it if not - let's develop it …

[[User:Felix Lange|Felix Lange]]14:56, 4 July 2014 (CEST) Thomas Kollatz is right, this tool is quite mature by now, making a new development from scratch pointless. But is there a programmatic (e.g. ReST) interface to the converter? If not, let's do it! @Frederike, some further project informations can be found at www.spatialhumanities.de/ibr, our project website.

=== Zotero ===
Some TEI encoding project may need to use a "master bibliography" to group together all the bibliographic references that are used in a given text or collection of texts. Using the "masterfile" option in Oxygen give the user a convenient way of pointing to a reference without having to encode a ref each time it is used in a text or in a specific bibliographic section.
<pre>
<bibl type="fromStone">
<ptr target="#Breal1878"/>
<citedRange>15</citedRange>
</bibl>
</pre>

The bibliography can be inserted in a <back/> element with xinclude. But the question is how to use Zotero to create this file, update it and synchonize it with the biblographic masterfile.
Though incomplete, the workflow I use works like that :
* the entering of the bibliographic entries is done with zotero, in a group library
* the zotero database is then exported in xml using the "bibliontology_rdf" format (the TEI export format being to restrictive in its formatting choices : e.g. does'nt include "short titles" which are a requisite in epigraphy
* the bibliontology rdf is converted in TEI through XSLT in Oxygen (modifying existing xslt :https://github.com/paregorios/Zotero-RDF-to-TEI-XML)
* If the user wants to add a new reference in the masterbibliography or correct an entry, he or she has to do go to zotero and follow the whole workflow of export - tranform process. But the user might not have the user right to do so. And of course, there are some potential conflicting issues.

How to improve that workflow ? use a version control system like git or subversion ? or adding/modifying an entry in xml / tei and then updating the zotero group library via api ?

'''Comments:'''
--[[User:Elli Bleeker|Elli Bleeker]] 15:29, 1 July 2014 (CEST) It seems that working with subversion would improve the workflow a lot and at least illiminate the risk of conflicting issues. Of course users should have the right to work in the (seperate) xml file of the bibliographic masterfile and add/change references. Once completed, the xml file can be exported to Zotero. In short, this would mean a reverse of the current workflow.

=== Migrating value lists form CSS frameworks to ODD ===

The author mode of the Oxygen editor can be customized with custom css functions. A part from the function providing a more user-friendly and tag free visualization of the tei content, one of the fuction allow the user to edit attributes or simple elements values using combo boxes or check boxes. The "form controls" can display values collected from an xml schema. But these values can also be just in the oxygen css. This may be used in a workflow to test some choices before integrating them in a more consistent and persistant way in the ODD (then exported in the schema).

This could be useful in case you have user that may be ok to change the values in the css code but would be relunctant to get involved with the ODD editing / schema generation process.
cf. http://www.oxygenxml.com/doc/ug-editor/concepts/combo-box-editor.html#combo-box-editor

'''Comments:'''

--[[User:Raffaele.viglianti|Raffaele.viglianti]] 19:20, 16 June 2014 (CEST) This is interesting, would like to work on it. I would suggest to make it less tied to Oxygen and think in terms of CSS to ODD, for example to limit attribute values (e.g. hi[rend=italic])

[[User:Elena Spadini|Elena Spadini]] 00:13, 24 June 2014 (CEST) I'm not well-exeperienced with the author mode in oXygen and its customizations, but I would like to explore it working on this project.

=== Visualization of intertextual TEI content ===
[UPDATED on June 24th]

The focus is on the possibilities offered by TEI XML for encoding intertextuality. The case study concerns the personal library of an author and a digital edition of his work. The objective is to encode the material in such a way that the intertextual relations between the literary work and its external sources is visualized.

These -sometimes subtle- intertextual relationships provide insight into the nature of writing, all the more since the genesis of the literary work itself is already encoded in the edition (i.e. adds, dels, etc.). The envisioned result enables a user to study the writing process in detail as well as on a larger scale.

Material:
* detailed XML TEI transcription of the literary work concerned
* high quality digital facsimiles of the author's personal '''extant''' library
* rough transcriptions of the library books (based on OCR)

'''Comments:'''

* Clarification: is the project about the visualization? the relationships? More detail would be great.
*
--[[User:Elli Bleeker|Elli Bleeker]] 15:46, 1 July 2014 (CEST) The idea is to log the complete <nowiki>"path"</nowiki> of a citation: from a phrase underlined in a library book to the incorporation of that phrase in the author's work.
Currently, the intertextual references are encoded with [ref] tag in the XML TEI transcription of the literary work. The [ref]s refer to another xml file containing the transcriptions of the personal library. This file consists of [div]s, that contain anything from a complete library book to a small section (paragraph, phrase) from a library book.

The visualization of the intertextual relations comes in a later stage when transforming the documents. I wonder whether it is possible to change or improve this encoding.

=== Rendering Complex Markup ===
Rendering complex markup in an innovative and playful way: reconstructing & visualizing author’s
geographical position by the dates of sending of his letters (taking uncertainty into account)

'''Comments:'''

[[User:Magdalena Turska|Magdalena Turska]] 12:36, 12 June 2014 (CEST)

Starting with a list of letters that have a place and date of sending the idea would be to present map overview of the author's journeys.
See the simple Google Map at https://mapsengine.google.com/map/edit?mid=z3q4AefiR7Us.kf1fVBHlu8qE

Fist ideas re visualisation:
* places color-coded with color getting darker to represent 'later' places
* similarly shaded lines along the routes between places
* animation with slider to show circle moving along the routes, size of the circle getting bigger with the uncertainty

Input data:
each letter has assigned place name and 1+ time intervals (notBefore to not After)

--[[User:Frederike Neuber|Frederike Neuber]] 22:25, 24 June 2014 (CEST)
Would it be a problem to work on different material? @TEI-experts
I would like to visualize the provenance of medieval manuscripts on a map, so even if I do not work with letters, the task is partly the same (extracting date and time from the <teiHeader> and visualizing it on a map). Then our scopes separate: Magdalena wants to reconstruct the journey, I want to visualize the chronology of different mss on one map.

[[User:Thomas Kollatz|Thomas Kollatz]] 15:56, 1 July 2014 (CEST)
I agree with [[User:Frederike Neuber|Frederike Neuber]]: the task is the same in all projects, where a spatio-temporal visualization makes sense: Extract date and time from header - and visualize the chronology of date/time and place on a map and/or timeline
/TEI/teiHeader/fileDesc/sourceDesc/msDesc/history/origin

=== Adding a TEI mode to a web editor ===
Title says it all!

'''Comments:'''

--[[User:Raffaele.viglianti|Raffaele.viglianti]] 19:20, 16 June 2014 (CEST) How does the [http://wiki.tei-c.org/index.php/DH2014Hackathon-Projects#ACE-based_Web_editor Angles] proposal above sound?

=== Juxta Script support ===
Adding support for Bengali text to Juxta Commons

'''Comments:'''
* This is fairly narrow.
[[User:Thomas Kollatz|Thomas Kollatz]] 15:57, 1 July 2014 (CEST) If Bengali then Hebrew (Arabic … right-to-left), please

=== Visualization ===
The archive of early Caribbean texts and images is a fairly large project which will be heavily encoded (and a portion of texts will be encoded by July). I'd like to explore ways of using the TEI to visualize relations between and among texts and elements of texts.

'''Comments:'''

--[[User:Elli Bleeker|Elli Bleeker]] 16:19, 1 July 2014 (CEST) What is the status of this project? I am also interested in finding ways to visualize relations between texts, perhaps there are similarities?

=== Jewish Sepulchral Headstones DB ===

Given that all headstones can be clearly located,
and about 20.000 (of total 26.000) inscriptions are dated,
and to a large extend can be distinguished by gender,
and also by language usage (hebrew, german, german in Hebrew letters, …),
they lend themselves to mining the epidat corpus for specific data facets and try to visualize the results "in an innovative and playful way".
#A challenging research questions could be the search for and visualization of the differences in word usage and specific idiomatic
## between different locations,
## within different periods (based on one or several locations),
## between inscriptions for men and inscriptions for women,
## between hebrew and non-hebrew inscriptions …
#Even more challenging is the search for inscriptions with very similar text coverage. These are quite difficult to discover by a simple full text search. The inscriptions are usually rather short, and the filter to develop has to consider the differentiating elements – usually names and dates – in order to determine, whether two text are identical or not.

All necessary information to answer this questions is contained in the metadata <teiHeader> and data <text> of each single record.
example – spatial and temporal metadata (date, country/region code, geo-coordinates, Thesaurus of Getty Names or OSM ID)
<history>
<origin>
<date notBefore='1621-08-17'>1621-08-17</date>
<country type="ISO_3166" key="XA-DE-HH">
Germany
<region>Hamburg</region>
</country>
<settlement type='city' key='tgn:7012310'>
Hamburg-Altona, Königstraße
<geogName>
Jüdischer Friedhof
<geo decls="#WGS">53.549373 9.950545</geo>
</geogName>
</settlement>
</origin>
</history>
example – gender-specific metadata (given according to ISO 5218:2004)
<particDesc>
<listPerson>
<person xml:id="hha-3361-1" s x='1'>
<persName>Schmuel ben Jehuda</persName>
<event when='1621-08-17' type="dateofdeath">
<desc/>
</event>
</person>
</listPerson>
</particDesc>
example – language Usage metadata:
<langUsage>

<language ident='he' usage='100'>Hebrew</language>
</langUsage>

With respect for the TEI Hackathon I have (just) set up a website with very general information how to harvest epidat records:
http://www.steinheim-institut.de/cgi-bin/epidat?info=howtoharvest (to be continued …)
Over and beyond that it would make no great difficulty to provide a zip file with the data available for the workshop.

'''Comments:'''
[[User:Thomas Kollatz|Thomas Kollatz]] 16:05, 1 July 2014 (CEST) The TEI spam filter seems to dislike the person-attribute s_x (middle-letter e) … rather prudish, isn't it

'''Discussion'''

What commonalities to you see? What seems interesting? Anything to add?

--[[User:Frederike Neuber|Frederike Neuber]] 23:21, 24 June 2014 (CEST)
Two (even if very different) projects, "Jewish Sepulchral Headstones DB" and "Rendering complex mark up", are dealing with visualization of spatial and temporal metadata.

Three (again very different) projects, "Visualization of intertextual TEI content", "Semantic Connections for Epigraphic Documents" and "Jewish Sepulchral Headstones DB", are dealing with semantic connection and modelling of content (even if not all of them say it explicitly in the description).

--[[User:Elli Bleeker|Elli Bleeker]] 16:25, 1 July 2014 (CEST)
Add to that the visualization of textual relations in the early Caribbean texts archive.

--[[User:Felix Lange| Felix Lange]] 16:30 4 July 2014 (CEST) - That's sounds pretty interesting, I'm on board. The text-analysis ("mining") part seems pretty tough, though. How exactly should the content of different inscriptions be compared? Do you think about general word-frequency-statistics, that can populate a Word-Cloud? Or do you plan text comparison that is "semantic" in a certain sense?

=== Core Builder ===
Another possible tool to work on: https://github.com/raffazizzi/coreBuilder
It provides a simple web interface to create stand-off markup. TEI files can be open into multiple ACE editors and the user can click on elements with xml:ids to create references.
The current version creates <app> elements containing <rdg>s with pointers to the selected elements. It should be easy enough to make the elements user configurable so that the Core Builder can be used to put together <linkGrp>s or <timeline>s.
The tool is written in CoffeScript with a [http://backbonejs.org/ Backbone] framework. --[[User:Raffaele.viglianti|Raffaele.viglianti]] 19:07, 16 June 2014 (CEST)

--[[User:Elli Bleeker|Elli Bleeker]] 16:23, 1 July 2014 (CEST) From the sound of it, I think I would like to work on this project. Some more detail would be great.

Here's a demo of the current version. It's got a few bugs but should show the basic functionality. Pick a couple of sources, then click on any element with xml:id to create a selection. Click add to save it to the "core". https://dl.dropboxusercontent.com/u/2443674/coreBuilder/index.html --[[User:Raffaele.viglianti|Raffaele.viglianti]] 02:31, 3 July 2014 (CEST)

DH2014Hackathon-Projects

2014-07-06T15:37:59Z

Rahtz: /* Suggested setup using Git */

= DH2014 Hackathon Project Discussion Page =

== Let's Hack ==

A suggestion for how to proceed based on the range of proposals and the range of participants. The group is likely to be able to sustain 2 or at most 3 projects in the time frame allotted. Some suggestions; please modify, develop or otherwise shape to your liking!

=== Suggested setup using Git ===

There is a Git repository at https://github.com/TEIC/Hackathon which can be used for any group during the Hackathon. Sebastian Rahtz can add people to the TEI group on request so that they have write access. You can use any Git client, obviously. If you don't have a client setup
already and are on a Mac, you'll find https://mac.github.com/ easy to set up and use. If you possibly can, get your account and setup ready before the meet.

This repository is synchronized with a web server at http://tei.it.ox.ac.uk/Hackathon/ every minute. This web server has a CORS setup, which should allow cross-site scripting to work for any
group working with JSON or other Ajax technique.

To test this, clone the Git repository on your local laptop and open the file map/maptest.html in your browser. It should read JSON data from
http://tei.it.ox.ac.uk/Hackathon/map/objects.json and display it on a map. If you add more JSON data files to the repository, and push them up to Github, they should appear on the web server quite quickly; similarly this can be used to "publish" HTML.

Sebastian will be available during the Hackathon to wrangle the web server as needed.

=== ODD visualizer ===

A group might try to put together a plan and start to code up an ODD visualizer. ODD is a literate programming language for XML schemas written by the TEI, and which is used to define the TEI schema. An ODD visualizer might be a component of an ODD customization tool such as the successor of Roma, and could provide information to a user about what modules they have included in their TEI schema, or what modification they have made.

The group should start by discussing what to visualize, perhaps including some TEI users who has experience in customization.

'''Resources:''' About ODD [http://www.tei-c.org/Support/Learn/odds.xml Getting Started with P5 ODDs], [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/USE.html Guidelines Chapter 23: Using the TEI] and a look at [http://www.tei-c.org/Roma/ Roma], the tool that is currently in use for generating TEI customizations.

--[[User:Elli Bleeker|Elli Bleeker]] 16:05, 4 July 2014 (CEST) I know of some digital edition projects that are a priori TEI compliant but have added their own custamizations if the TEI Guidelines did not offer a sufficient solution for the <nowiki>"challenge"</nowiki> posed by the text. I can imagine there are more projects that do so. Is that meant by <nowiki>"modification"</nowiki> of the TEI schema?
It seems the ODD visualizer might be a good addition to the authorial workflow as described below, if it offers the editors insight in their specific text encoding methods.

[[User:Elena Spadini|Elena Spadini]] 12:13, 5 July 2014 (CEST) (I'm not sure this is the right place for adding names to a project as Elli wrote us, but) I would like to work on it!

[[User:Raffaele.viglianti|Raffaele.viglianti]] 13:40, 6 July 2014 (CEST) I'd happily work on this

=== Basic framework for rendering a document and creating simple visualizations ===

This project could be quite extensive, so the group should begin by selecting components that they can manage.

The proposed outcome is to be able to display (or at least mine) a document for salient features, and to produce output generic enough that it can be passed to either mapping or to other visualization software. Or perhaps to the NY Times Pourover js library. One possible way to to do this is to decide on a json data structure, as that is a popular format for visualization libraries.

--[[User:Frederike Neuber|Frederike Neuber]] 08:08, 3 July 2014 (CEST) Are you referring to a particular visualization software on which it might be useful to take a quick look before the hackathon?

--[[User:Elli Mylonas|Elli Mylonas]] 11:27, 4 July 2014 (CEST) Frederike has a good comment - are there suggestions? Google Maps is one idea. Leaflet, and D3 (more complex) are others. Thoughts?

--[[User:Rahtz|Rahtz]] 17:02, 6 July 2014 (CEST) I would suggest we limit ourselves for this project to Leaflet (mapping) and D3 (graphs) with its companion C3. Both have loads of examples and addons. Leaflet rather than Google Maps because it doesn't need API keys etc, and can use other tiles easily. The key thing here is to proof of concept - get a visualization up and running quickly, then tweak it. If its successful, recoding it later in another library is not so hard. Note, however, that we come up against cross-site scripting which we read JSON in an HTML file. See Setup section above.

=== Develop the MS description framework ===

This was one of the proposed projects that got a lot of comments. It could be developed along the lines of the comments, and generalized a bit.

[[User:Alexander Czmiel|Alexander Czmiel]] 14:20, 4 July 2014 (CEST) Maybe I don't get it, but it seems to me this project has the same aims like "Basic framework for rendering a document". Anyway, rendering TEI documents is an imortant issue which has not been adressed enough in the past. Especially when looking on complex markup such as recommended by the Genetic Markup SIG.
There are already a few approaches which try to do exactly the same, we want to do here: build a generic framework to publish TEI documents online. There is eLaborate (http://elaborate.huygens.knaw.nl/) from Den Haag, xMod (http://www.cch.kcl.ac.uk/xmod/) from London, DENQ from Rome, and SADE (best/current version on Github by vronk: https://github.com/vronk/SADE) which we try to build in Berlin/Göttingen/Wien. To a certain point OMEKA (http://www.omeka.net/) could be used as well, I think. There are many more, I don't know of. So please don't let us start from the scratch with a new project.

--[[User:Elli Bleeker|Elli Bleeker]] 14:56, 4 July 2014 (CEST) I agree it would be pointless to start from scratch. But it might be worth considering to further develop one of the abovementioned approaches. I am not familiar with all of them, but most tend to fail once the textual genetics becomes more complex. The fact that many of the proposed projects in this Hackathon are aimed at the rendering of complex TEI mark up, suggests that this is one of the most important needs of textual scholars and that there is still no sufficient way to do so.

--[[User:Frederike Neuber|Frederike Neuber]] 19:27, 4 July 2014 (CEST) It seems we have all different understandings of the project's descriptions - I will tell you mine too: 
In my opinion the two project aim different results, even if the workflow will be partly the same. 
The "rendering complex markup.." aims to offer in a creative visualization of the extracted data, so this project will be about including visualization software which supports data visualization beyond lists and timelines. 
The "MS description.." aims (or at least it did in the beginning) to create a framework which is applicable to each TEI-document containing a <msDesc> part and includes both displaying the <msDesc> content (in an linear way, no tricky visualization) and search and browse functions. The scope of this project is to provide in the end a set of files which anyone can use to render a <msDesc> part. 
So far.. can somebody bring light into the darkness please? :)

[[User:Patrik Granholm|Patrik Granholm]] 23:35, 4 July 2014 (CEST) My initial proposal was to create a simple search and browsing interface for MS descriptions which would be general enough to be used by other similar projects. But perhaps it is too specific. An interface for TEI-files in general would probably be more useful. The idea is that everything should be well documented so that people with limited programming skills would be able to modify the code to suit their needs. It would be more like an eXist template than a finished product.

[[User:Elena Spadini|Elena Spadini]] 12:08, 5 July 2014 (CEST) I don't think that it is too specific and an interface for TEI files in general is probably too wide for one day. For sure there are a lot of projects flourishing in this way (not eLaborate that is at a certain point TEI compliant but not at all TEI based), as everyone using TEI deals with the problems and find more or less home made solutions. But if during the Hackathon something can be started and finished, it would be a really good result!

--[[User:Frederike Neuber|Frederike Neuber]] 15:55, 5 July 2014 (CEST) Maybe we could decide whether we want to render the metadata or the text. I think some templates for rendering the <teiHeader> with focusing on search options (searching for certain fields, combining them, faceted search) would be nice. 
Can someone provide some XML files to work with?

[[User:Patrik Granholm|Patrik Granholm]] 08:55, 6 July 2014 (CEST) I have a few preliminary MS descriptions from our cataloguing project, and quite a large collection of MS descriptions from other projects which we could work with.

=== Discussing, working out and documenting best practices for an authoring workflow ===

Projects that last for many years, have many people working on them, and comprise large amounts of material need to ensure that work is being done efficiently, produce accurate output, and move files through transformations and validations. Good workflows can be enhanced by both tools and best practices. The outcome of this project could be a document with explanation and examples of authoring/encoding/proofreading/version control workflows with a focus on software tools.

--[[User:Elli Bleeker|Elli Bleeker]] 15:22, 4 July 2014 (CEST) Would we aim at enhancing the workflow of existing projects or suggest best practices for future projects? It would be very interesting to see whether it is possible to distinguish a best practice for an authoring workflow. Normally projects that run for many years and started <nowiki>"back in the days"</nowiki> have developed their own ad hoc workflow. They happily admit to have done things differently witht the knowledge of today. Of course the workflow depends upon the people working on it (trained editors, volunteers through crowd-sourcing...).
Perhaps the outcome would be several different workflows, depending on the type of material, the objectives of the project and the people collaborating on it.

== Participants ==

* [http://mith.umd.edu/people/person/raffaele-viglianti/ Raffaele Viglianti], University of Maryland
* [http://www.patrikgranholm.com Patrik Granholm], Uppsala University Library: [http://www.manuscripta.se Greek Manuscripts in Sweden. A Digitization and Cataloguing Project]
* [http://online.uni-graz.at/kfu_online/visitenkarte.show_vcard?pPersonenId=9570FBD84B50B383&pPersonenGruppe=3 Frederike Neuber], DiXiT - research fellow at Graz University - Austrian Centre for Digital Humanities
* Felix Lange, Academy of Sciences and Literature | Mainz, Project IBR (http://www.spatialhumanities.de)
* Emmanuelle Morlock, CNRS, HISoMA Laboratory (Histoire et Sources des mondes antiques / History and Origins of the Antique World)
* [https://www.uantwerpen.be/en/staff/elli-bleeker/ Elli Bleeker], PhD student in Digital Humanities at Antwerp University; research fellow at DiXiT
* Magdalena Turska, University of Oxford
* Nick Laiacona, Performant Software Solutions LLC www.performantsoftware.com
* Elizabeth Maddock Dillon, Professor of English and CoDirector of NULab for Texts, Maps, and Networks, Northeastern University, Boston, MA USA
* [http://steinheim-institut.de/wiki/index.php/Mitarbeiter:Thomas_Kollatz Thomas Kollatz], Steinheim-Institute for German-Jewish History: [http://steinheim-institut.de/cgi-bin/epidat epidat]
* Elena Spadini, Huygens Ing

* Sebastian Rahtz, University of Oxford
* James Cummings, University of Oxford
* [http://www.i-d-e.de/mitglieder/alexander-czmiel Alex Czmiel], Berlin-Brandenburg Academy of Sciences and Humanities
* Hugh Cayless, Duke University
* Elli Mylonas, Brown University

== Procedure ==

We will be using the wiki as a place for comments and discussion. The projects each participant proposed are all listed below. Ideally, the hackathon will be focussed around one or two projects that are useful to everyone. The participants are all experienced with TEI in various capacities, but they are not all skilled programmers. The hackathon would be a success if the outcome of the one day event was e a good start on one or two useful pieces of TEI related software. In order to achieve this, we should collectively decide on projects that are interesting, useful, generalizable, and do-able! We should also try to capitalize on everyone's skill set, and try to plan the event in such a way that we can all contribute to something.

You are all welcome to introduce yourselves, by adding a description of a few sentences to the list of participants above. And please, edit, correct and comment on the projects. We are also inviting the TEI Council and Board and other interested parties to look in on the discussions.

== Proposed Projects ==

=== Mormon City Planning: ===
when early Mormonism ventured from Kirtland, Ohio, into Missouri, their prophet Joseph Smith Jr provided a revelation for the plat (city layout) of the new Zion (http://urbanplanning.library.cornell.edu/DOCS/smith.htm; http://zomarah.files.wordpress.com/2010/10/firstplatofzion.png), which was subsequently applied in the settlement of Far West, Missouri, for which two plats exist, one on sheepskin (https://www.lds.org/bc/content/shared/content/images/gospel-library/manual/32502/15-02 b.gif) in private possession and one on paper at BYU University (there is no online copy of this, but I have obtained a digital copy from BYU with their permission); however these plats were not only used to sketch out the city, but also to assign lots to settlers, and thus show secondary markup in pencil to allocate houses, redraw lot boundaries, etc; (http://zomarah.files.wordpress.com/2010/10/platoffarwestbig.png)

'''Comments:'''
* A clarification: What would the project strive to accomplish? Is this a visualization? georeferencing based on markup?
* [[User:Thomas Kollatz|Thomas Kollatz]] 11:57, 1 July 2014 (CEST) https://www.lds.org/bc/content/shared/content/images/gospel-library/manual/32502/15-02 error 404 - not found; maybe visualization: text-information encoded in TEI related to city layout ("plat") in SVG ?

=== ODD Customization visualizer ===
A web-based tool to visualize any ODD customization against TEI-all. This could be useful when working on a customization (with Roma, or manually) to quickly and visually check that the ODD is still TEI-conformant and see how it diverges from the standard.
I started working on a basic D3 visualization a couple of years ago, but haven't really touched the code since:https://github.com/raffazizzi/ODDViz I only restructured the repository a bit before sending this proposal.

'''Comments'''
A simple demo: https://dl.dropboxusercontent.com/u/2443674/ODDViz/index.html --[[User:Raffaele.viglianti|Raffaele.viglianti]] 03:02, 3 July 2014 (CEST)

=== ACE-based Web editor ===

MITH, at the University of Maryland has been working on an ACE-based web editor able to validate tei-all files in the browser and provide ODD-based contextual help (e.g. suggesting valid options when entering a new element).
The grant that funded this work is now over, but there's plenty more to do. This is the GitHub repository: https://github.com/umd-mith/angles

'''Comments:'''

=== MS Description Display Framework ===
To create a simple web interface which would provide basic functionalities like browsing, searching and displaying TEI-files containing manuscript descriptions. The interface could be built using a Ubuntu server with [http://nginx.org nginx], and [http://exist-db.org eXist-db] following the setup guide and scripts provided by [https://github.com/grantmacken/nginx-eXist-ubuntu Grant Macken]. I have already made some preliminary work on an eXist-db web interface and posted the code in our [https://github.com/manuscripta GitHub repository]. This could be used as a starting point for further development. A possible goal for the hackathon could be to create an advanced search form in XQuery which would display snippets of the descriptions in the search results using the transform function with our XSL stylesheet, with links to the full description. All of the code, with detailed documentation, would be made public on GitHub for others to reuse and modify for their own projects. I think this would be beneficial to the TEI community at large, and especially to other cataloguing projects.

'''Comments:'''

* I believe this would be really useful project, especially if we build it not only having this particular purpose of MS descriptions in mind, but something more general, so other users would potentially swap only source files and stylesheets and would have a basic working website. [[User:Magdalena Turska|Magdalena Turska]] 11:00, 23 June 2014 (CEST)
* me too – more general features almost every project will need after swapping source files and stylesheets: navigation to next page/object ; or: navigation to next entry/object in chronological order, full text search everywhere resp in particular div's (type="edition") etc. [[User:Thomas Kollatz|Thomas Kollatz]] 12:09, 1 July 2014 (CEST)
* I am definitely open to creating a more general display framework in eXist. Perhaps we could make use of Joe Wicentowski’s [http://digital.humanities.ox.ac.uk/dhoxss/2011/presentations/Wicentowski-XMLDatabases-materials.zip Punch eXist tutorial] from DHOxSS 2011. [[User:Patrik Granholm|Patrik Granholm]] 11:16, 2 July 2014 (CEST)

=== Medieval Text Edition ===

<strike>
Project isn't advanced enough to suggest concrete task, but the topic of interest is focussed around a digital scholarly edition of a medieval text (with corresponding images) encoded in XML/TEI. The edition will be enriched with palaeographical and codicological information (in both <text> and <teiHeader>) and the results can be visualized in a way which hopefully goes beyond the sometimes not very enlightening listing of data.</strike>

'''Comments:'''
Even now my project is not advanced enough to be used for the hackathon. I will join the discussions on the other projects. --[[User:Frederike Neuber|Frederike Neuber]] 22:05, 24 June 2014 (CEST)

=== Semantic Connections for Epigraphic Documents ===
I am currently working with epidoc documents in the context of the Project IBR. These documents, epigraphical editions from the catalogue "German Inscriptions Online" (inschriften.net), are (1) to be transformed into RDFtriples for semantic connection and for a finegrained quantificational analysis in a Triple Store, (2) XSLT transformed into HTMLDocuments for further annotation in the semantic annotator "Pundit"(thepund.it). I could surely contribute a programming task based on this points, but would also be happy to participate in another task, preferably based on "adding a TEI mode to a web editor".

'''Comments:'''

--[[User:Frederike Neuber|Frederike Neuber]] 23:02, 24 June 2014 (CEST) Who is responsible for this project and can provide further information?
I would be very interested in joining this project even if I can't offer material and even if I do not understand one step: how can you transform an epidoc document into RDF triples? Do you mean you generate RDF from the annotated entities (extracting them?)? And how do you do it, are there tools or software to support it?

[[User:Thomas Kollatz|Thomas Kollatz]] 12:12, 1 July 2014 (CEST) The [http://www.tei-c.org/oxgarage/ oxgarage] magic box contains already a tool converting TEI2RDF, if so – we should try it out and evaluate it if not - let's develop it …

[[User:Felix Lange|Felix Lange]]14:56, 4 July 2014 (CEST) Thomas Kollatz is right, this tool is quite mature by now, making a new development from scratch pointless. But is there a programmatic (e.g. ReST) interface to the converter? If not, let's do it! @Frederike, some further project informations can be found at www.spatialhumanities.de/ibr, our project website.

=== Zotero ===
Some TEI encoding project may need to use a "master bibliography" to group together all the bibliographic references that are used in a given text or collection of texts. Using the "masterfile" option in Oxygen give the user a convenient way of pointing to a reference without having to encode a ref each time it is used in a text or in a specific bibliographic section.
<pre>
<bibl type="fromStone">
<ptr target="#Breal1878"/>
<citedRange>15</citedRange>
</bibl>
</pre>

The bibliography can be inserted in a <back/> element with xinclude. But the question is how to use Zotero to create this file, update it and synchonize it with the biblographic masterfile.
Though incomplete, the workflow I use works like that :
* the entering of the bibliographic entries is done with zotero, in a group library
* the zotero database is then exported in xml using the "bibliontology_rdf" format (the TEI export format being to restrictive in its formatting choices : e.g. does'nt include "short titles" which are a requisite in epigraphy
* the bibliontology rdf is converted in TEI through XSLT in Oxygen (modifying existing xslt :https://github.com/paregorios/Zotero-RDF-to-TEI-XML)
* If the user wants to add a new reference in the masterbibliography or correct an entry, he or she has to do go to zotero and follow the whole workflow of export - tranform process. But the user might not have the user right to do so. And of course, there are some potential conflicting issues.

How to improve that workflow ? use a version control system like git or subversion ? or adding/modifying an entry in xml / tei and then updating the zotero group library via api ?

'''Comments:'''
--[[User:Elli Bleeker|Elli Bleeker]] 15:29, 1 July 2014 (CEST) It seems that working with subversion would improve the workflow a lot and at least illiminate the risk of conflicting issues. Of course users should have the right to work in the (seperate) xml file of the bibliographic masterfile and add/change references. Once completed, the xml file can be exported to Zotero. In short, this would mean a reverse of the current workflow.

=== Migrating value lists form CSS frameworks to ODD ===

The author mode of the Oxygen editor can be customized with custom css functions. A part from the function providing a more user-friendly and tag free visualization of the tei content, one of the fuction allow the user to edit attributes or simple elements values using combo boxes or check boxes. The "form controls" can display values collected from an xml schema. But these values can also be just in the oxygen css. This may be used in a workflow to test some choices before integrating them in a more consistent and persistant way in the ODD (then exported in the schema).

This could be useful in case you have user that may be ok to change the values in the css code but would be relunctant to get involved with the ODD editing / schema generation process.
cf. http://www.oxygenxml.com/doc/ug-editor/concepts/combo-box-editor.html#combo-box-editor

'''Comments:'''

--[[User:Raffaele.viglianti|Raffaele.viglianti]] 19:20, 16 June 2014 (CEST) This is interesting, would like to work on it. I would suggest to make it less tied to Oxygen and think in terms of CSS to ODD, for example to limit attribute values (e.g. hi[rend=italic])

[[User:Elena Spadini|Elena Spadini]] 00:13, 24 June 2014 (CEST) I'm not well-exeperienced with the author mode in oXygen and its customizations, but I would like to explore it working on this project.

=== Visualization of intertextual TEI content ===
[UPDATED on June 24th]

The focus is on the possibilities offered by TEI XML for encoding intertextuality. The case study concerns the personal library of an author and a digital edition of his work. The objective is to encode the material in such a way that the intertextual relations between the literary work and its external sources is visualized.

These -sometimes subtle- intertextual relationships provide insight into the nature of writing, all the more since the genesis of the literary work itself is already encoded in the edition (i.e. adds, dels, etc.). The envisioned result enables a user to study the writing process in detail as well as on a larger scale.

Material:
* detailed XML TEI transcription of the literary work concerned
* high quality digital facsimiles of the author's personal '''extant''' library
* rough transcriptions of the library books (based on OCR)

'''Comments:'''

* Clarification: is the project about the visualization? the relationships? More detail would be great.
*
--[[User:Elli Bleeker|Elli Bleeker]] 15:46, 1 July 2014 (CEST) The idea is to log the complete <nowiki>"path"</nowiki> of a citation: from a phrase underlined in a library book to the incorporation of that phrase in the author's work.
Currently, the intertextual references are encoded with [ref] tag in the XML TEI transcription of the literary work. The [ref]s refer to another xml file containing the transcriptions of the personal library. This file consists of [div]s, that contain anything from a complete library book to a small section (paragraph, phrase) from a library book.

The visualization of the intertextual relations comes in a later stage when transforming the documents. I wonder whether it is possible to change or improve this encoding.

=== Rendering Complex Markup ===
Rendering complex markup in an innovative and playful way: reconstructing & visualizing author’s
geographical position by the dates of sending of his letters (taking uncertainty into account)

'''Comments:'''

[[User:Magdalena Turska|Magdalena Turska]] 12:36, 12 June 2014 (CEST)

Starting with a list of letters that have a place and date of sending the idea would be to present map overview of the author's journeys.
See the simple Google Map at https://mapsengine.google.com/map/edit?mid=z3q4AefiR7Us.kf1fVBHlu8qE

Fist ideas re visualisation:
* places color-coded with color getting darker to represent 'later' places
* similarly shaded lines along the routes between places
* animation with slider to show circle moving along the routes, size of the circle getting bigger with the uncertainty

Input data:
each letter has assigned place name and 1+ time intervals (notBefore to not After)

--[[User:Frederike Neuber|Frederike Neuber]] 22:25, 24 June 2014 (CEST)
Would it be a problem to work on different material? @TEI-experts
I would like to visualize the provenance of medieval manuscripts on a map, so even if I do not work with letters, the task is partly the same (extracting date and time from the <teiHeader> and visualizing it on a map). Then our scopes separate: Magdalena wants to reconstruct the journey, I want to visualize the chronology of different mss on one map.

[[User:Thomas Kollatz|Thomas Kollatz]] 15:56, 1 July 2014 (CEST)
I agree with [[User:Frederike Neuber|Frederike Neuber]]: the task is the same in all projects, where a spatio-temporal visualization makes sense: Extract date and time from header - and visualize the chronology of date/time and place on a map and/or timeline
/TEI/teiHeader/fileDesc/sourceDesc/msDesc/history/origin

=== Adding a TEI mode to a web editor ===
Title says it all!

'''Comments:'''

--[[User:Raffaele.viglianti|Raffaele.viglianti]] 19:20, 16 June 2014 (CEST) How does the [http://wiki.tei-c.org/index.php/DH2014Hackathon-Projects#ACE-based_Web_editor Angles] proposal above sound?

=== Juxta Script support ===
Adding support for Bengali text to Juxta Commons

'''Comments:'''
* This is fairly narrow.
[[User:Thomas Kollatz|Thomas Kollatz]] 15:57, 1 July 2014 (CEST) If Bengali then Hebrew (Arabic … right-to-left), please

=== Visualization ===
The archive of early Caribbean texts and images is a fairly large project which will be heavily encoded (and a portion of texts will be encoded by July). I'd like to explore ways of using the TEI to visualize relations between and among texts and elements of texts.

'''Comments:'''

--[[User:Elli Bleeker|Elli Bleeker]] 16:19, 1 July 2014 (CEST) What is the status of this project? I am also interested in finding ways to visualize relations between texts, perhaps there are similarities?

=== Jewish Sepulchral Headstones DB ===

Given that all headstones can be clearly located,
and about 20.000 (of total 26.000) inscriptions are dated,
and to a large extend can be distinguished by gender,
and also by language usage (hebrew, german, german in Hebrew letters, …),
they lend themselves to mining the epidat corpus for specific data facets and try to visualize the results "in an innovative and playful way".
#A challenging research questions could be the search for and visualization of the differences in word usage and specific idiomatic
## between different locations,
## within different periods (based on one or several locations),
## between inscriptions for men and inscriptions for women,
## between hebrew and non-hebrew inscriptions …
#Even more challenging is the search for inscriptions with very similar text coverage. These are quite difficult to discover by a simple full text search. The inscriptions are usually rather short, and the filter to develop has to consider the differentiating elements – usually names and dates – in order to determine, whether two text are identical or not.

All necessary information to answer this questions is contained in the metadata <teiHeader> and data <text> of each single record.
example – spatial and temporal metadata (date, country/region code, geo-coordinates, Thesaurus of Getty Names or OSM ID)
<history>
<origin>
<date notBefore='1621-08-17'>1621-08-17</date>
<country type="ISO_3166" key="XA-DE-HH">
Germany
<region>Hamburg</region>
</country>
<settlement type='city' key='tgn:7012310'>
Hamburg-Altona, Königstraße
<geogName>
Jüdischer Friedhof
<geo decls="#WGS">53.549373 9.950545</geo>
</geogName>
</settlement>
</origin>
</history>
example – gender-specific metadata (given according to ISO 5218:2004)
<particDesc>
<listPerson>
<person xml:id="hha-3361-1" s x='1'>
<persName>Schmuel ben Jehuda</persName>
<event when='1621-08-17' type="dateofdeath">
<desc/>
</event>
</person>
</listPerson>
</particDesc>
example – language Usage metadata:
<langUsage>

<language ident='he' usage='100'>Hebrew</language>
</langUsage>

With respect for the TEI Hackathon I have (just) set up a website with very general information how to harvest epidat records:
http://www.steinheim-institut.de/cgi-bin/epidat?info=howtoharvest (to be continued …)
Over and beyond that it would make no great difficulty to provide a zip file with the data available for the workshop.

'''Comments:'''
[[User:Thomas Kollatz|Thomas Kollatz]] 16:05, 1 July 2014 (CEST) The TEI spam filter seems to dislike the person-attribute s_x (middle-letter e) … rather prudish, isn't it

'''Discussion'''

What commonalities to you see? What seems interesting? Anything to add?

--[[User:Frederike Neuber|Frederike Neuber]] 23:21, 24 June 2014 (CEST)
Two (even if very different) projects, "Jewish Sepulchral Headstones DB" and "Rendering complex mark up", are dealing with visualization of spatial and temporal metadata.

Three (again very different) projects, "Visualization of intertextual TEI content", "Semantic Connections for Epigraphic Documents" and "Jewish Sepulchral Headstones DB", are dealing with semantic connection and modelling of content (even if not all of them say it explicitly in the description).

--[[User:Elli Bleeker|Elli Bleeker]] 16:25, 1 July 2014 (CEST)
Add to that the visualization of textual relations in the early Caribbean texts archive.

--[[User:Felix Lange| Felix Lange]] 16:30 4 July 2014 (CEST) - That's sounds pretty interesting, I'm on board. The text-analysis ("mining") part seems pretty tough, though. How exactly should the content of different inscriptions be compared? Do you think about general word-frequency-statistics, that can populate a Word-Cloud? Or do you plan text comparison that is "semantic" in a certain sense?

=== Core Builder ===
Another possible tool to work on: https://github.com/raffazizzi/coreBuilder
It provides a simple web interface to create stand-off markup. TEI files can be open into multiple ACE editors and the user can click on elements with xml:ids to create references.
The current version creates <app> elements containing <rdg>s with pointers to the selected elements. It should be easy enough to make the elements user configurable so that the Core Builder can be used to put together <linkGrp>s or <timeline>s.
The tool is written in CoffeScript with a [http://backbonejs.org/ Backbone] framework. --[[User:Raffaele.viglianti|Raffaele.viglianti]] 19:07, 16 June 2014 (CEST)

--[[User:Elli Bleeker|Elli Bleeker]] 16:23, 1 July 2014 (CEST) From the sound of it, I think I would like to work on this project. Some more detail would be great.

Here's a demo of the current version. It's got a few bugs but should show the basic functionality. Pick a couple of sources, then click on any element with xml:id to create a selection. Click add to save it to the "core". https://dl.dropboxusercontent.com/u/2443674/coreBuilder/index.html --[[User:Raffaele.viglianti|Raffaele.viglianti]] 02:31, 3 July 2014 (CEST)

DH2014Hackathon-Projects

2014-07-06T15:23:55Z

Rahtz: /* Let's Hack */

= DH2014 Hackathon Project Discussion Page =

== Let's Hack ==

A suggestion for how to proceed based on the range of proposals and the range of participants. The group is likely to be able to sustain 2 or at most 3 projects in the time frame allotted. Some suggestions; please modify, develop or otherwise shape to your liking!

=== Suggested setup using Git ===

There is a Git repository at https://github.com/TEIC/Hackathon which can be used for any group during the Hackathon. Sebastian Rahtz can add people to the TEI group on request so that they have write access. This repository is synchronized with a web server at http://tei.it.ox.ac.uk/Hackathon/ every minute. This web server has a CORS setup, which should allow cross-site scripting to work for any
group working with JSON or other Ajax technique.

To test this, clone the Git repository on your local laptop and open the file map/maptest.html in your browser. It should read JSON data from
http://tei.it.ox.ac.uk/Hackathon/map/objects.json and display it on a map. If you add more JSON data files to the repository, and push them up to Github, they should appear on the web server quite quickly; similarly this can be used to "publish" HTML.

Sebastian will be available during the Hackathon to wrangle the web server as needed.

=== ODD visualizer ===

A group might try to put together a plan and start to code up an ODD visualizer. ODD is a literate programming language for XML schemas written by the TEI, and which is used to define the TEI schema. An ODD visualizer might be a component of an ODD customization tool such as the successor of Roma, and could provide information to a user about what modules they have included in their TEI schema, or what modification they have made.

The group should start by discussing what to visualize, perhaps including some TEI users who has experience in customization.

'''Resources:''' About ODD [http://www.tei-c.org/Support/Learn/odds.xml Getting Started with P5 ODDs], [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/USE.html Guidelines Chapter 23: Using the TEI] and a look at [http://www.tei-c.org/Roma/ Roma], the tool that is currently in use for generating TEI customizations.

--[[User:Elli Bleeker|Elli Bleeker]] 16:05, 4 July 2014 (CEST) I know of some digital edition projects that are a priori TEI compliant but have added their own custamizations if the TEI Guidelines did not offer a sufficient solution for the <nowiki>"challenge"</nowiki> posed by the text. I can imagine there are more projects that do so. Is that meant by <nowiki>"modification"</nowiki> of the TEI schema?
It seems the ODD visualizer might be a good addition to the authorial workflow as described below, if it offers the editors insight in their specific text encoding methods.

[[User:Elena Spadini|Elena Spadini]] 12:13, 5 July 2014 (CEST) (I'm not sure this is the right place for adding names to a project as Elli wrote us, but) I would like to work on it!

[[User:Raffaele.viglianti|Raffaele.viglianti]] 13:40, 6 July 2014 (CEST) I'd happily work on this

=== Basic framework for rendering a document and creating simple visualizations ===

This project could be quite extensive, so the group should begin by selecting components that they can manage.

The proposed outcome is to be able to display (or at least mine) a document for salient features, and to produce output generic enough that it can be passed to either mapping or to other visualization software. Or perhaps to the NY Times Pourover js library. One possible way to to do this is to decide on a json data structure, as that is a popular format for visualization libraries.

--[[User:Frederike Neuber|Frederike Neuber]] 08:08, 3 July 2014 (CEST) Are you referring to a particular visualization software on which it might be useful to take a quick look before the hackathon?

--[[User:Elli Mylonas|Elli Mylonas]] 11:27, 4 July 2014 (CEST) Frederike has a good comment - are there suggestions? Google Maps is one idea. Leaflet, and D3 (more complex) are others. Thoughts?

--[[User:Rahtz|Rahtz]] 17:02, 6 July 2014 (CEST) I would suggest we limit ourselves for this project to Leaflet (mapping) and D3 (graphs) with its companion C3. Both have loads of examples and addons. Leaflet rather than Google Maps because it doesn't need API keys etc, and can use other tiles easily. The key thing here is to proof of concept - get a visualization up and running quickly, then tweak it. If its successful, recoding it later in another library is not so hard. Note, however, that we come up against cross-site scripting which we read JSON in an HTML file. See Setup section above.

=== Develop the MS description framework ===

This was one of the proposed projects that got a lot of comments. It could be developed along the lines of the comments, and generalized a bit.

[[User:Alexander Czmiel|Alexander Czmiel]] 14:20, 4 July 2014 (CEST) Maybe I don't get it, but it seems to me this project has the same aims like "Basic framework for rendering a document". Anyway, rendering TEI documents is an imortant issue which has not been adressed enough in the past. Especially when looking on complex markup such as recommended by the Genetic Markup SIG.
There are already a few approaches which try to do exactly the same, we want to do here: build a generic framework to publish TEI documents online. There is eLaborate (http://elaborate.huygens.knaw.nl/) from Den Haag, xMod (http://www.cch.kcl.ac.uk/xmod/) from London, DENQ from Rome, and SADE (best/current version on Github by vronk: https://github.com/vronk/SADE) which we try to build in Berlin/Göttingen/Wien. To a certain point OMEKA (http://www.omeka.net/) could be used as well, I think. There are many more, I don't know of. So please don't let us start from the scratch with a new project.

--[[User:Elli Bleeker|Elli Bleeker]] 14:56, 4 July 2014 (CEST) I agree it would be pointless to start from scratch. But it might be worth considering to further develop one of the abovementioned approaches. I am not familiar with all of them, but most tend to fail once the textual genetics becomes more complex. The fact that many of the proposed projects in this Hackathon are aimed at the rendering of complex TEI mark up, suggests that this is one of the most important needs of textual scholars and that there is still no sufficient way to do so.

--[[User:Frederike Neuber|Frederike Neuber]] 19:27, 4 July 2014 (CEST) It seems we have all different understandings of the project's descriptions - I will tell you mine too: 
In my opinion the two project aim different results, even if the workflow will be partly the same. 
The "rendering complex markup.." aims to offer in a creative visualization of the extracted data, so this project will be about including visualization software which supports data visualization beyond lists and timelines. 
The "MS description.." aims (or at least it did in the beginning) to create a framework which is applicable to each TEI-document containing a <msDesc> part and includes both displaying the <msDesc> content (in an linear way, no tricky visualization) and search and browse functions. The scope of this project is to provide in the end a set of files which anyone can use to render a <msDesc> part. 
So far.. can somebody bring light into the darkness please? :)

[[User:Patrik Granholm|Patrik Granholm]] 23:35, 4 July 2014 (CEST) My initial proposal was to create a simple search and browsing interface for MS descriptions which would be general enough to be used by other similar projects. But perhaps it is too specific. An interface for TEI-files in general would probably be more useful. The idea is that everything should be well documented so that people with limited programming skills would be able to modify the code to suit their needs. It would be more like an eXist template than a finished product.

[[User:Elena Spadini|Elena Spadini]] 12:08, 5 July 2014 (CEST) I don't think that it is too specific and an interface for TEI files in general is probably too wide for one day. For sure there are a lot of projects flourishing in this way (not eLaborate that is at a certain point TEI compliant but not at all TEI based), as everyone using TEI deals with the problems and find more or less home made solutions. But if during the Hackathon something can be started and finished, it would be a really good result!

--[[User:Frederike Neuber|Frederike Neuber]] 15:55, 5 July 2014 (CEST) Maybe we could decide whether we want to render the metadata or the text. I think some templates for rendering the <teiHeader> with focusing on search options (searching for certain fields, combining them, faceted search) would be nice. 
Can someone provide some XML files to work with?

[[User:Patrik Granholm|Patrik Granholm]] 08:55, 6 July 2014 (CEST) I have a few preliminary MS descriptions from our cataloguing project, and quite a large collection of MS descriptions from other projects which we could work with.

=== Discussing, working out and documenting best practices for an authoring workflow ===

Projects that last for many years, have many people working on them, and comprise large amounts of material need to ensure that work is being done efficiently, produce accurate output, and move files through transformations and validations. Good workflows can be enhanced by both tools and best practices. The outcome of this project could be a document with explanation and examples of authoring/encoding/proofreading/version control workflows with a focus on software tools.

--[[User:Elli Bleeker|Elli Bleeker]] 15:22, 4 July 2014 (CEST) Would we aim at enhancing the workflow of existing projects or suggest best practices for future projects? It would be very interesting to see whether it is possible to distinguish a best practice for an authoring workflow. Normally projects that run for many years and started <nowiki>"back in the days"</nowiki> have developed their own ad hoc workflow. They happily admit to have done things differently witht the knowledge of today. Of course the workflow depends upon the people working on it (trained editors, volunteers through crowd-sourcing...).
Perhaps the outcome would be several different workflows, depending on the type of material, the objectives of the project and the people collaborating on it.

== Participants ==

* [http://mith.umd.edu/people/person/raffaele-viglianti/ Raffaele Viglianti], University of Maryland
* [http://www.patrikgranholm.com Patrik Granholm], Uppsala University Library: [http://www.manuscripta.se Greek Manuscripts in Sweden. A Digitization and Cataloguing Project]
* [http://online.uni-graz.at/kfu_online/visitenkarte.show_vcard?pPersonenId=9570FBD84B50B383&pPersonenGruppe=3 Frederike Neuber], DiXiT - research fellow at Graz University - Austrian Centre for Digital Humanities
* Felix Lange, Academy of Sciences and Literature | Mainz, Project IBR (http://www.spatialhumanities.de)
* Emmanuelle Morlock, CNRS, HISoMA Laboratory (Histoire et Sources des mondes antiques / History and Origins of the Antique World)
* [https://www.uantwerpen.be/en/staff/elli-bleeker/ Elli Bleeker], PhD student in Digital Humanities at Antwerp University; research fellow at DiXiT
* Magdalena Turska, University of Oxford
* Nick Laiacona, Performant Software Solutions LLC www.performantsoftware.com
* Elizabeth Maddock Dillon, Professor of English and CoDirector of NULab for Texts, Maps, and Networks, Northeastern University, Boston, MA USA
* [http://steinheim-institut.de/wiki/index.php/Mitarbeiter:Thomas_Kollatz Thomas Kollatz], Steinheim-Institute for German-Jewish History: [http://steinheim-institut.de/cgi-bin/epidat epidat]
* Elena Spadini, Huygens Ing

* Sebastian Rahtz, University of Oxford
* James Cummings, University of Oxford
* [http://www.i-d-e.de/mitglieder/alexander-czmiel Alex Czmiel], Berlin-Brandenburg Academy of Sciences and Humanities
* Hugh Cayless, Duke University
* Elli Mylonas, Brown University

== Procedure ==

We will be using the wiki as a place for comments and discussion. The projects each participant proposed are all listed below. Ideally, the hackathon will be focussed around one or two projects that are useful to everyone. The participants are all experienced with TEI in various capacities, but they are not all skilled programmers. The hackathon would be a success if the outcome of the one day event was e a good start on one or two useful pieces of TEI related software. In order to achieve this, we should collectively decide on projects that are interesting, useful, generalizable, and do-able! We should also try to capitalize on everyone's skill set, and try to plan the event in such a way that we can all contribute to something.

You are all welcome to introduce yourselves, by adding a description of a few sentences to the list of participants above. And please, edit, correct and comment on the projects. We are also inviting the TEI Council and Board and other interested parties to look in on the discussions.

== Proposed Projects ==

=== Mormon City Planning: ===
when early Mormonism ventured from Kirtland, Ohio, into Missouri, their prophet Joseph Smith Jr provided a revelation for the plat (city layout) of the new Zion (http://urbanplanning.library.cornell.edu/DOCS/smith.htm; http://zomarah.files.wordpress.com/2010/10/firstplatofzion.png), which was subsequently applied in the settlement of Far West, Missouri, for which two plats exist, one on sheepskin (https://www.lds.org/bc/content/shared/content/images/gospel-library/manual/32502/15-02 b.gif) in private possession and one on paper at BYU University (there is no online copy of this, but I have obtained a digital copy from BYU with their permission); however these plats were not only used to sketch out the city, but also to assign lots to settlers, and thus show secondary markup in pencil to allocate houses, redraw lot boundaries, etc; (http://zomarah.files.wordpress.com/2010/10/platoffarwestbig.png)

'''Comments:'''
* A clarification: What would the project strive to accomplish? Is this a visualization? georeferencing based on markup?
* [[User:Thomas Kollatz|Thomas Kollatz]] 11:57, 1 July 2014 (CEST) https://www.lds.org/bc/content/shared/content/images/gospel-library/manual/32502/15-02 error 404 - not found; maybe visualization: text-information encoded in TEI related to city layout ("plat") in SVG ?

=== ODD Customization visualizer ===
A web-based tool to visualize any ODD customization against TEI-all. This could be useful when working on a customization (with Roma, or manually) to quickly and visually check that the ODD is still TEI-conformant and see how it diverges from the standard.
I started working on a basic D3 visualization a couple of years ago, but haven't really touched the code since:https://github.com/raffazizzi/ODDViz I only restructured the repository a bit before sending this proposal.

'''Comments'''
A simple demo: https://dl.dropboxusercontent.com/u/2443674/ODDViz/index.html --[[User:Raffaele.viglianti|Raffaele.viglianti]] 03:02, 3 July 2014 (CEST)

=== ACE-based Web editor ===

MITH, at the University of Maryland has been working on an ACE-based web editor able to validate tei-all files in the browser and provide ODD-based contextual help (e.g. suggesting valid options when entering a new element).
The grant that funded this work is now over, but there's plenty more to do. This is the GitHub repository: https://github.com/umd-mith/angles

'''Comments:'''

=== MS Description Display Framework ===
To create a simple web interface which would provide basic functionalities like browsing, searching and displaying TEI-files containing manuscript descriptions. The interface could be built using a Ubuntu server with [http://nginx.org nginx], and [http://exist-db.org eXist-db] following the setup guide and scripts provided by [https://github.com/grantmacken/nginx-eXist-ubuntu Grant Macken]. I have already made some preliminary work on an eXist-db web interface and posted the code in our [https://github.com/manuscripta GitHub repository]. This could be used as a starting point for further development. A possible goal for the hackathon could be to create an advanced search form in XQuery which would display snippets of the descriptions in the search results using the transform function with our XSL stylesheet, with links to the full description. All of the code, with detailed documentation, would be made public on GitHub for others to reuse and modify for their own projects. I think this would be beneficial to the TEI community at large, and especially to other cataloguing projects.

'''Comments:'''

* I believe this would be really useful project, especially if we build it not only having this particular purpose of MS descriptions in mind, but something more general, so other users would potentially swap only source files and stylesheets and would have a basic working website. [[User:Magdalena Turska|Magdalena Turska]] 11:00, 23 June 2014 (CEST)
* me too – more general features almost every project will need after swapping source files and stylesheets: navigation to next page/object ; or: navigation to next entry/object in chronological order, full text search everywhere resp in particular div's (type="edition") etc. [[User:Thomas Kollatz|Thomas Kollatz]] 12:09, 1 July 2014 (CEST)
* I am definitely open to creating a more general display framework in eXist. Perhaps we could make use of Joe Wicentowski’s [http://digital.humanities.ox.ac.uk/dhoxss/2011/presentations/Wicentowski-XMLDatabases-materials.zip Punch eXist tutorial] from DHOxSS 2011. [[User:Patrik Granholm|Patrik Granholm]] 11:16, 2 July 2014 (CEST)

=== Medieval Text Edition ===

<strike>
Project isn't advanced enough to suggest concrete task, but the topic of interest is focussed around a digital scholarly edition of a medieval text (with corresponding images) encoded in XML/TEI. The edition will be enriched with palaeographical and codicological information (in both <text> and <teiHeader>) and the results can be visualized in a way which hopefully goes beyond the sometimes not very enlightening listing of data.</strike>

'''Comments:'''
Even now my project is not advanced enough to be used for the hackathon. I will join the discussions on the other projects. --[[User:Frederike Neuber|Frederike Neuber]] 22:05, 24 June 2014 (CEST)

=== Semantic Connections for Epigraphic Documents ===
I am currently working with epidoc documents in the context of the Project IBR. These documents, epigraphical editions from the catalogue "German Inscriptions Online" (inschriften.net), are (1) to be transformed into RDFtriples for semantic connection and for a finegrained quantificational analysis in a Triple Store, (2) XSLT transformed into HTMLDocuments for further annotation in the semantic annotator "Pundit"(thepund.it). I could surely contribute a programming task based on this points, but would also be happy to participate in another task, preferably based on "adding a TEI mode to a web editor".

'''Comments:'''

--[[User:Frederike Neuber|Frederike Neuber]] 23:02, 24 June 2014 (CEST) Who is responsible for this project and can provide further information?
I would be very interested in joining this project even if I can't offer material and even if I do not understand one step: how can you transform an epidoc document into RDF triples? Do you mean you generate RDF from the annotated entities (extracting them?)? And how do you do it, are there tools or software to support it?

[[User:Thomas Kollatz|Thomas Kollatz]] 12:12, 1 July 2014 (CEST) The [http://www.tei-c.org/oxgarage/ oxgarage] magic box contains already a tool converting TEI2RDF, if so – we should try it out and evaluate it if not - let's develop it …

[[User:Felix Lange|Felix Lange]]14:56, 4 July 2014 (CEST) Thomas Kollatz is right, this tool is quite mature by now, making a new development from scratch pointless. But is there a programmatic (e.g. ReST) interface to the converter? If not, let's do it! @Frederike, some further project informations can be found at www.spatialhumanities.de/ibr, our project website.

=== Zotero ===
Some TEI encoding project may need to use a "master bibliography" to group together all the bibliographic references that are used in a given text or collection of texts. Using the "masterfile" option in Oxygen give the user a convenient way of pointing to a reference without having to encode a ref each time it is used in a text or in a specific bibliographic section.
<pre>
<bibl type="fromStone">
<ptr target="#Breal1878"/>
<citedRange>15</citedRange>
</bibl>
</pre>

The bibliography can be inserted in a <back/> element with xinclude. But the question is how to use Zotero to create this file, update it and synchonize it with the biblographic masterfile.
Though incomplete, the workflow I use works like that :
* the entering of the bibliographic entries is done with zotero, in a group library
* the zotero database is then exported in xml using the "bibliontology_rdf" format (the TEI export format being to restrictive in its formatting choices : e.g. does'nt include "short titles" which are a requisite in epigraphy
* the bibliontology rdf is converted in TEI through XSLT in Oxygen (modifying existing xslt :https://github.com/paregorios/Zotero-RDF-to-TEI-XML)
* If the user wants to add a new reference in the masterbibliography or correct an entry, he or she has to do go to zotero and follow the whole workflow of export - tranform process. But the user might not have the user right to do so. And of course, there are some potential conflicting issues.

How to improve that workflow ? use a version control system like git or subversion ? or adding/modifying an entry in xml / tei and then updating the zotero group library via api ?

'''Comments:'''
--[[User:Elli Bleeker|Elli Bleeker]] 15:29, 1 July 2014 (CEST) It seems that working with subversion would improve the workflow a lot and at least illiminate the risk of conflicting issues. Of course users should have the right to work in the (seperate) xml file of the bibliographic masterfile and add/change references. Once completed, the xml file can be exported to Zotero. In short, this would mean a reverse of the current workflow.

=== Migrating value lists form CSS frameworks to ODD ===

The author mode of the Oxygen editor can be customized with custom css functions. A part from the function providing a more user-friendly and tag free visualization of the tei content, one of the fuction allow the user to edit attributes or simple elements values using combo boxes or check boxes. The "form controls" can display values collected from an xml schema. But these values can also be just in the oxygen css. This may be used in a workflow to test some choices before integrating them in a more consistent and persistant way in the ODD (then exported in the schema).

This could be useful in case you have user that may be ok to change the values in the css code but would be relunctant to get involved with the ODD editing / schema generation process.
cf. http://www.oxygenxml.com/doc/ug-editor/concepts/combo-box-editor.html#combo-box-editor

'''Comments:'''

--[[User:Raffaele.viglianti|Raffaele.viglianti]] 19:20, 16 June 2014 (CEST) This is interesting, would like to work on it. I would suggest to make it less tied to Oxygen and think in terms of CSS to ODD, for example to limit attribute values (e.g. hi[rend=italic])

[[User:Elena Spadini|Elena Spadini]] 00:13, 24 June 2014 (CEST) I'm not well-exeperienced with the author mode in oXygen and its customizations, but I would like to explore it working on this project.

=== Visualization of intertextual TEI content ===
[UPDATED on June 24th]

The focus is on the possibilities offered by TEI XML for encoding intertextuality. The case study concerns the personal library of an author and a digital edition of his work. The objective is to encode the material in such a way that the intertextual relations between the literary work and its external sources is visualized.

These -sometimes subtle- intertextual relationships provide insight into the nature of writing, all the more since the genesis of the literary work itself is already encoded in the edition (i.e. adds, dels, etc.). The envisioned result enables a user to study the writing process in detail as well as on a larger scale.

Material:
* detailed XML TEI transcription of the literary work concerned
* high quality digital facsimiles of the author's personal '''extant''' library
* rough transcriptions of the library books (based on OCR)

'''Comments:'''

* Clarification: is the project about the visualization? the relationships? More detail would be great.
*
--[[User:Elli Bleeker|Elli Bleeker]] 15:46, 1 July 2014 (CEST) The idea is to log the complete <nowiki>"path"</nowiki> of a citation: from a phrase underlined in a library book to the incorporation of that phrase in the author's work.
Currently, the intertextual references are encoded with [ref] tag in the XML TEI transcription of the literary work. The [ref]s refer to another xml file containing the transcriptions of the personal library. This file consists of [div]s, that contain anything from a complete library book to a small section (paragraph, phrase) from a library book.

The visualization of the intertextual relations comes in a later stage when transforming the documents. I wonder whether it is possible to change or improve this encoding.

=== Rendering Complex Markup ===
Rendering complex markup in an innovative and playful way: reconstructing & visualizing author’s
geographical position by the dates of sending of his letters (taking uncertainty into account)

'''Comments:'''

[[User:Magdalena Turska|Magdalena Turska]] 12:36, 12 June 2014 (CEST)

Starting with a list of letters that have a place and date of sending the idea would be to present map overview of the author's journeys.
See the simple Google Map at https://mapsengine.google.com/map/edit?mid=z3q4AefiR7Us.kf1fVBHlu8qE

Fist ideas re visualisation:
* places color-coded with color getting darker to represent 'later' places
* similarly shaded lines along the routes between places
* animation with slider to show circle moving along the routes, size of the circle getting bigger with the uncertainty

Input data:
each letter has assigned place name and 1+ time intervals (notBefore to not After)

--[[User:Frederike Neuber|Frederike Neuber]] 22:25, 24 June 2014 (CEST)
Would it be a problem to work on different material? @TEI-experts
I would like to visualize the provenance of medieval manuscripts on a map, so even if I do not work with letters, the task is partly the same (extracting date and time from the <teiHeader> and visualizing it on a map). Then our scopes separate: Magdalena wants to reconstruct the journey, I want to visualize the chronology of different mss on one map.

[[User:Thomas Kollatz|Thomas Kollatz]] 15:56, 1 July 2014 (CEST)
I agree with [[User:Frederike Neuber|Frederike Neuber]]: the task is the same in all projects, where a spatio-temporal visualization makes sense: Extract date and time from header - and visualize the chronology of date/time and place on a map and/or timeline
/TEI/teiHeader/fileDesc/sourceDesc/msDesc/history/origin

=== Adding a TEI mode to a web editor ===
Title says it all!

'''Comments:'''

--[[User:Raffaele.viglianti|Raffaele.viglianti]] 19:20, 16 June 2014 (CEST) How does the [http://wiki.tei-c.org/index.php/DH2014Hackathon-Projects#ACE-based_Web_editor Angles] proposal above sound?

=== Juxta Script support ===
Adding support for Bengali text to Juxta Commons

'''Comments:'''
* This is fairly narrow.
[[User:Thomas Kollatz|Thomas Kollatz]] 15:57, 1 July 2014 (CEST) If Bengali then Hebrew (Arabic … right-to-left), please

=== Visualization ===
The archive of early Caribbean texts and images is a fairly large project which will be heavily encoded (and a portion of texts will be encoded by July). I'd like to explore ways of using the TEI to visualize relations between and among texts and elements of texts.

'''Comments:'''

--[[User:Elli Bleeker|Elli Bleeker]] 16:19, 1 July 2014 (CEST) What is the status of this project? I am also interested in finding ways to visualize relations between texts, perhaps there are similarities?

=== Jewish Sepulchral Headstones DB ===

Given that all headstones can be clearly located,
and about 20.000 (of total 26.000) inscriptions are dated,
and to a large extend can be distinguished by gender,
and also by language usage (hebrew, german, german in Hebrew letters, …),
they lend themselves to mining the epidat corpus for specific data facets and try to visualize the results "in an innovative and playful way".
#A challenging research questions could be the search for and visualization of the differences in word usage and specific idiomatic
## between different locations,
## within different periods (based on one or several locations),
## between inscriptions for men and inscriptions for women,
## between hebrew and non-hebrew inscriptions …
#Even more challenging is the search for inscriptions with very similar text coverage. These are quite difficult to discover by a simple full text search. The inscriptions are usually rather short, and the filter to develop has to consider the differentiating elements – usually names and dates – in order to determine, whether two text are identical or not.

All necessary information to answer this questions is contained in the metadata <teiHeader> and data <text> of each single record.
example – spatial and temporal metadata (date, country/region code, geo-coordinates, Thesaurus of Getty Names or OSM ID)
<history>
<origin>
<date notBefore='1621-08-17'>1621-08-17</date>
<country type="ISO_3166" key="XA-DE-HH">
Germany
<region>Hamburg</region>
</country>
<settlement type='city' key='tgn:7012310'>
Hamburg-Altona, Königstraße
<geogName>
Jüdischer Friedhof
<geo decls="#WGS">53.549373 9.950545</geo>
</geogName>
</settlement>
</origin>
</history>
example – gender-specific metadata (given according to ISO 5218:2004)
<particDesc>
<listPerson>
<person xml:id="hha-3361-1" s x='1'>
<persName>Schmuel ben Jehuda</persName>
<event when='1621-08-17' type="dateofdeath">
<desc/>
</event>
</person>
</listPerson>
</particDesc>
example – language Usage metadata:
<langUsage>

<language ident='he' usage='100'>Hebrew</language>
</langUsage>

With respect for the TEI Hackathon I have (just) set up a website with very general information how to harvest epidat records:
http://www.steinheim-institut.de/cgi-bin/epidat?info=howtoharvest (to be continued …)
Over and beyond that it would make no great difficulty to provide a zip file with the data available for the workshop.

'''Comments:'''
[[User:Thomas Kollatz|Thomas Kollatz]] 16:05, 1 July 2014 (CEST) The TEI spam filter seems to dislike the person-attribute s_x (middle-letter e) … rather prudish, isn't it

'''Discussion'''

What commonalities to you see? What seems interesting? Anything to add?

--[[User:Frederike Neuber|Frederike Neuber]] 23:21, 24 June 2014 (CEST)
Two (even if very different) projects, "Jewish Sepulchral Headstones DB" and "Rendering complex mark up", are dealing with visualization of spatial and temporal metadata.

Three (again very different) projects, "Visualization of intertextual TEI content", "Semantic Connections for Epigraphic Documents" and "Jewish Sepulchral Headstones DB", are dealing with semantic connection and modelling of content (even if not all of them say it explicitly in the description).

--[[User:Elli Bleeker|Elli Bleeker]] 16:25, 1 July 2014 (CEST)
Add to that the visualization of textual relations in the early Caribbean texts archive.

--[[User:Felix Lange| Felix Lange]] 16:30 4 July 2014 (CEST) - That's sounds pretty interesting, I'm on board. The text-analysis ("mining") part seems pretty tough, though. How exactly should the content of different inscriptions be compared? Do you think about general word-frequency-statistics, that can populate a Word-Cloud? Or do you plan text comparison that is "semantic" in a certain sense?

=== Core Builder ===
Another possible tool to work on: https://github.com/raffazizzi/coreBuilder
It provides a simple web interface to create stand-off markup. TEI files can be open into multiple ACE editors and the user can click on elements with xml:ids to create references.
The current version creates <app> elements containing <rdg>s with pointers to the selected elements. It should be easy enough to make the elements user configurable so that the Core Builder can be used to put together <linkGrp>s or <timeline>s.
The tool is written in CoffeScript with a [http://backbonejs.org/ Backbone] framework. --[[User:Raffaele.viglianti|Raffaele.viglianti]] 19:07, 16 June 2014 (CEST)

--[[User:Elli Bleeker|Elli Bleeker]] 16:23, 1 July 2014 (CEST) From the sound of it, I think I would like to work on this project. Some more detail would be great.

Here's a demo of the current version. It's got a few bugs but should show the basic functionality. Pick a couple of sources, then click on any element with xml:id to create a selection. Click add to save it to the "core". https://dl.dropboxusercontent.com/u/2443674/coreBuilder/index.html --[[User:Raffaele.viglianti|Raffaele.viglianti]] 02:31, 3 July 2014 (CEST)

DH2014Hackathon-Projects

2014-07-06T15:02:46Z

Rahtz: /* Basic framework for rendering a document and creating simple visualizations */

= DH2014 Hackathon Project Discussion Page =

== Let's Hack ==

A suggestion for how to proceed based on the range of proposals and the range of participants. The group is likely to be able to sustain 2 or at most 3 projects in the time frame allotted. Some suggestions; please modify, develop or otherwise shape to your liking!

=== ODD visualizer ===

A group might try to put together a plan and start to code up an ODD visualizer. ODD is a literate programming language for XML schemas written by the TEI, and which is used to define the TEI schema. An ODD visualizer might be a component of an ODD customization tool such as the successor of Roma, and could provide information to a user about what modules they have included in their TEI schema, or what modification they have made.

The group should start by discussing what to visualize, perhaps including some TEI users who has experience in customization.

'''Resources:''' About ODD [http://www.tei-c.org/Support/Learn/odds.xml Getting Started with P5 ODDs], [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/USE.html Guidelines Chapter 23: Using the TEI] and a look at [http://www.tei-c.org/Roma/ Roma], the tool that is currently in use for generating TEI customizations.

--[[User:Elli Bleeker|Elli Bleeker]] 16:05, 4 July 2014 (CEST) I know of some digital edition projects that are a priori TEI compliant but have added their own custamizations if the TEI Guidelines did not offer a sufficient solution for the <nowiki>"challenge"</nowiki> posed by the text. I can imagine there are more projects that do so. Is that meant by <nowiki>"modification"</nowiki> of the TEI schema?
It seems the ODD visualizer might be a good addition to the authorial workflow as described below, if it offers the editors insight in their specific text encoding methods.

[[User:Elena Spadini|Elena Spadini]] 12:13, 5 July 2014 (CEST) (I'm not sure this is the right place for adding names to a project as Elli wrote us, but) I would like to work on it!

[[User:Raffaele.viglianti|Raffaele.viglianti]] 13:40, 6 July 2014 (CEST) I'd happily work on this

=== Basic framework for rendering a document and creating simple visualizations ===

This project could be quite extensive, so the group should begin by selecting components that they can manage.

The proposed outcome is to be able to display (or at least mine) a document for salient features, and to produce output generic enough that it can be passed to either mapping or to other visualization software. Or perhaps to the NY Times Pourover js library. One possible way to to do this is to decide on a json data structure, as that is a popular format for visualization libraries.

--[[User:Frederike Neuber|Frederike Neuber]] 08:08, 3 July 2014 (CEST) Are you referring to a particular visualization software on which it might be useful to take a quick look before the hackathon?

--[[User:Elli Mylonas|Elli Mylonas]] 11:27, 4 July 2014 (CEST) Frederike has a good comment - are there suggestions? Google Maps is one idea. Leaflet, and D3 (more complex) are others. Thoughts?

--[[User:Rahtz|Rahtz]] 17:02, 6 July 2014 (CEST) I would suggest we limit ourselves for this project to Leaflet (mapping) and D3 (graphs) with its companion C3. Both have loads of examples and addons. Leaflet rather than Google Maps because it doesn't need API keys etc, and can use other tiles easily. The key thing here is to proof of concept - get a visualization up and running quickly, then tweak it. If its successful, recoding it later in another library is not so hard. Note, however, that we come up against cross-site scripting which we read JSON in an HTML file. See Setup section above.

=== Develop the MS description framework ===

This was one of the proposed projects that got a lot of comments. It could be developed along the lines of the comments, and generalized a bit.

[[User:Alexander Czmiel|Alexander Czmiel]] 14:20, 4 July 2014 (CEST) Maybe I don't get it, but it seems to me this project has the same aims like "Basic framework for rendering a document". Anyway, rendering TEI documents is an imortant issue which has not been adressed enough in the past. Especially when looking on complex markup such as recommended by the Genetic Markup SIG.
There are already a few approaches which try to do exactly the same, we want to do here: build a generic framework to publish TEI documents online. There is eLaborate (http://elaborate.huygens.knaw.nl/) from Den Haag, xMod (http://www.cch.kcl.ac.uk/xmod/) from London, DENQ from Rome, and SADE (best/current version on Github by vronk: https://github.com/vronk/SADE) which we try to build in Berlin/Göttingen/Wien. To a certain point OMEKA (http://www.omeka.net/) could be used as well, I think. There are many more, I don't know of. So please don't let us start from the scratch with a new project.

--[[User:Elli Bleeker|Elli Bleeker]] 14:56, 4 July 2014 (CEST) I agree it would be pointless to start from scratch. But it might be worth considering to further develop one of the abovementioned approaches. I am not familiar with all of them, but most tend to fail once the textual genetics becomes more complex. The fact that many of the proposed projects in this Hackathon are aimed at the rendering of complex TEI mark up, suggests that this is one of the most important needs of textual scholars and that there is still no sufficient way to do so.

--[[User:Frederike Neuber|Frederike Neuber]] 19:27, 4 July 2014 (CEST) It seems we have all different understandings of the project's descriptions - I will tell you mine too: 
In my opinion the two project aim different results, even if the workflow will be partly the same. 
The "rendering complex markup.." aims to offer in a creative visualization of the extracted data, so this project will be about including visualization software which supports data visualization beyond lists and timelines. 
The "MS description.." aims (or at least it did in the beginning) to create a framework which is applicable to each TEI-document containing a <msDesc> part and includes both displaying the <msDesc> content (in an linear way, no tricky visualization) and search and browse functions. The scope of this project is to provide in the end a set of files which anyone can use to render a <msDesc> part. 
So far.. can somebody bring light into the darkness please? :)

[[User:Patrik Granholm|Patrik Granholm]] 23:35, 4 July 2014 (CEST) My initial proposal was to create a simple search and browsing interface for MS descriptions which would be general enough to be used by other similar projects. But perhaps it is too specific. An interface for TEI-files in general would probably be more useful. The idea is that everything should be well documented so that people with limited programming skills would be able to modify the code to suit their needs. It would be more like an eXist template than a finished product.

[[User:Elena Spadini|Elena Spadini]] 12:08, 5 July 2014 (CEST) I don't think that it is too specific and an interface for TEI files in general is probably too wide for one day. For sure there are a lot of projects flourishing in this way (not eLaborate that is at a certain point TEI compliant but not at all TEI based), as everyone using TEI deals with the problems and find more or less home made solutions. But if during the Hackathon something can be started and finished, it would be a really good result!

--[[User:Frederike Neuber|Frederike Neuber]] 15:55, 5 July 2014 (CEST) Maybe we could decide whether we want to render the metadata or the text. I think some templates for rendering the <teiHeader> with focusing on search options (searching for certain fields, combining them, faceted search) would be nice. 
Can someone provide some XML files to work with?

[[User:Patrik Granholm|Patrik Granholm]] 08:55, 6 July 2014 (CEST) I have a few preliminary MS descriptions from our cataloguing project, and quite a large collection of MS descriptions from other projects which we could work with.

=== Discussing, working out and documenting best practices for an authoring workflow ===

Projects that last for many years, have many people working on them, and comprise large amounts of material need to ensure that work is being done efficiently, produce accurate output, and move files through transformations and validations. Good workflows can be enhanced by both tools and best practices. The outcome of this project could be a document with explanation and examples of authoring/encoding/proofreading/version control workflows with a focus on software tools.

--[[User:Elli Bleeker|Elli Bleeker]] 15:22, 4 July 2014 (CEST) Would we aim at enhancing the workflow of existing projects or suggest best practices for future projects? It would be very interesting to see whether it is possible to distinguish a best practice for an authoring workflow. Normally projects that run for many years and started <nowiki>"back in the days"</nowiki> have developed their own ad hoc workflow. They happily admit to have done things differently witht the knowledge of today. Of course the workflow depends upon the people working on it (trained editors, volunteers through crowd-sourcing...).
Perhaps the outcome would be several different workflows, depending on the type of material, the objectives of the project and the people collaborating on it.

== Participants ==

* [http://mith.umd.edu/people/person/raffaele-viglianti/ Raffaele Viglianti], University of Maryland
* [http://www.patrikgranholm.com Patrik Granholm], Uppsala University Library: [http://www.manuscripta.se Greek Manuscripts in Sweden. A Digitization and Cataloguing Project]
* [http://online.uni-graz.at/kfu_online/visitenkarte.show_vcard?pPersonenId=9570FBD84B50B383&pPersonenGruppe=3 Frederike Neuber], DiXiT - research fellow at Graz University - Austrian Centre for Digital Humanities
* Felix Lange, Academy of Sciences and Literature | Mainz, Project IBR (http://www.spatialhumanities.de)
* Emmanuelle Morlock, CNRS, HISoMA Laboratory (Histoire et Sources des mondes antiques / History and Origins of the Antique World)
* [https://www.uantwerpen.be/en/staff/elli-bleeker/ Elli Bleeker], PhD student in Digital Humanities at Antwerp University; research fellow at DiXiT
* Magdalena Turska, University of Oxford
* Nick Laiacona, Performant Software Solutions LLC www.performantsoftware.com
* Elizabeth Maddock Dillon, Professor of English and CoDirector of NULab for Texts, Maps, and Networks, Northeastern University, Boston, MA USA
* [http://steinheim-institut.de/wiki/index.php/Mitarbeiter:Thomas_Kollatz Thomas Kollatz], Steinheim-Institute for German-Jewish History: [http://steinheim-institut.de/cgi-bin/epidat epidat]
* Elena Spadini, Huygens Ing

* Sebastian Rahtz, University of Oxford
* James Cummings, University of Oxford
* [http://www.i-d-e.de/mitglieder/alexander-czmiel Alex Czmiel], Berlin-Brandenburg Academy of Sciences and Humanities
* Hugh Cayless, Duke University
* Elli Mylonas, Brown University

== Procedure ==

We will be using the wiki as a place for comments and discussion. The projects each participant proposed are all listed below. Ideally, the hackathon will be focussed around one or two projects that are useful to everyone. The participants are all experienced with TEI in various capacities, but they are not all skilled programmers. The hackathon would be a success if the outcome of the one day event was e a good start on one or two useful pieces of TEI related software. In order to achieve this, we should collectively decide on projects that are interesting, useful, generalizable, and do-able! We should also try to capitalize on everyone's skill set, and try to plan the event in such a way that we can all contribute to something.

You are all welcome to introduce yourselves, by adding a description of a few sentences to the list of participants above. And please, edit, correct and comment on the projects. We are also inviting the TEI Council and Board and other interested parties to look in on the discussions.

== Proposed Projects ==

=== Mormon City Planning: ===
when early Mormonism ventured from Kirtland, Ohio, into Missouri, their prophet Joseph Smith Jr provided a revelation for the plat (city layout) of the new Zion (http://urbanplanning.library.cornell.edu/DOCS/smith.htm; http://zomarah.files.wordpress.com/2010/10/firstplatofzion.png), which was subsequently applied in the settlement of Far West, Missouri, for which two plats exist, one on sheepskin (https://www.lds.org/bc/content/shared/content/images/gospel-library/manual/32502/15-02 b.gif) in private possession and one on paper at BYU University (there is no online copy of this, but I have obtained a digital copy from BYU with their permission); however these plats were not only used to sketch out the city, but also to assign lots to settlers, and thus show secondary markup in pencil to allocate houses, redraw lot boundaries, etc; (http://zomarah.files.wordpress.com/2010/10/platoffarwestbig.png)

'''Comments:'''
* A clarification: What would the project strive to accomplish? Is this a visualization? georeferencing based on markup?
* [[User:Thomas Kollatz|Thomas Kollatz]] 11:57, 1 July 2014 (CEST) https://www.lds.org/bc/content/shared/content/images/gospel-library/manual/32502/15-02 error 404 - not found; maybe visualization: text-information encoded in TEI related to city layout ("plat") in SVG ?

=== ODD Customization visualizer ===
A web-based tool to visualize any ODD customization against TEI-all. This could be useful when working on a customization (with Roma, or manually) to quickly and visually check that the ODD is still TEI-conformant and see how it diverges from the standard.
I started working on a basic D3 visualization a couple of years ago, but haven't really touched the code since:https://github.com/raffazizzi/ODDViz I only restructured the repository a bit before sending this proposal.

'''Comments'''
A simple demo: https://dl.dropboxusercontent.com/u/2443674/ODDViz/index.html --[[User:Raffaele.viglianti|Raffaele.viglianti]] 03:02, 3 July 2014 (CEST)

=== ACE-based Web editor ===

MITH, at the University of Maryland has been working on an ACE-based web editor able to validate tei-all files in the browser and provide ODD-based contextual help (e.g. suggesting valid options when entering a new element).
The grant that funded this work is now over, but there's plenty more to do. This is the GitHub repository: https://github.com/umd-mith/angles

'''Comments:'''

=== MS Description Display Framework ===
To create a simple web interface which would provide basic functionalities like browsing, searching and displaying TEI-files containing manuscript descriptions. The interface could be built using a Ubuntu server with [http://nginx.org nginx], and [http://exist-db.org eXist-db] following the setup guide and scripts provided by [https://github.com/grantmacken/nginx-eXist-ubuntu Grant Macken]. I have already made some preliminary work on an eXist-db web interface and posted the code in our [https://github.com/manuscripta GitHub repository]. This could be used as a starting point for further development. A possible goal for the hackathon could be to create an advanced search form in XQuery which would display snippets of the descriptions in the search results using the transform function with our XSL stylesheet, with links to the full description. All of the code, with detailed documentation, would be made public on GitHub for others to reuse and modify for their own projects. I think this would be beneficial to the TEI community at large, and especially to other cataloguing projects.

'''Comments:'''

* I believe this would be really useful project, especially if we build it not only having this particular purpose of MS descriptions in mind, but something more general, so other users would potentially swap only source files and stylesheets and would have a basic working website. [[User:Magdalena Turska|Magdalena Turska]] 11:00, 23 June 2014 (CEST)
* me too – more general features almost every project will need after swapping source files and stylesheets: navigation to next page/object ; or: navigation to next entry/object in chronological order, full text search everywhere resp in particular div's (type="edition") etc. [[User:Thomas Kollatz|Thomas Kollatz]] 12:09, 1 July 2014 (CEST)
* I am definitely open to creating a more general display framework in eXist. Perhaps we could make use of Joe Wicentowski’s [http://digital.humanities.ox.ac.uk/dhoxss/2011/presentations/Wicentowski-XMLDatabases-materials.zip Punch eXist tutorial] from DHOxSS 2011. [[User:Patrik Granholm|Patrik Granholm]] 11:16, 2 July 2014 (CEST)

=== Medieval Text Edition ===

<strike>
Project isn't advanced enough to suggest concrete task, but the topic of interest is focussed around a digital scholarly edition of a medieval text (with corresponding images) encoded in XML/TEI. The edition will be enriched with palaeographical and codicological information (in both <text> and <teiHeader>) and the results can be visualized in a way which hopefully goes beyond the sometimes not very enlightening listing of data.</strike>

'''Comments:'''
Even now my project is not advanced enough to be used for the hackathon. I will join the discussions on the other projects. --[[User:Frederike Neuber|Frederike Neuber]] 22:05, 24 June 2014 (CEST)

=== Semantic Connections for Epigraphic Documents ===
I am currently working with epidoc documents in the context of the Project IBR. These documents, epigraphical editions from the catalogue "German Inscriptions Online" (inschriften.net), are (1) to be transformed into RDFtriples for semantic connection and for a finegrained quantificational analysis in a Triple Store, (2) XSLT transformed into HTMLDocuments for further annotation in the semantic annotator "Pundit"(thepund.it). I could surely contribute a programming task based on this points, but would also be happy to participate in another task, preferably based on "adding a TEI mode to a web editor".

'''Comments:'''

--[[User:Frederike Neuber|Frederike Neuber]] 23:02, 24 June 2014 (CEST) Who is responsible for this project and can provide further information?
I would be very interested in joining this project even if I can't offer material and even if I do not understand one step: how can you transform an epidoc document into RDF triples? Do you mean you generate RDF from the annotated entities (extracting them?)? And how do you do it, are there tools or software to support it?

[[User:Thomas Kollatz|Thomas Kollatz]] 12:12, 1 July 2014 (CEST) The [http://www.tei-c.org/oxgarage/ oxgarage] magic box contains already a tool converting TEI2RDF, if so – we should try it out and evaluate it if not - let's develop it …

[[User:Felix Lange|Felix Lange]]14:56, 4 July 2014 (CEST) Thomas Kollatz is right, this tool is quite mature by now, making a new development from scratch pointless. But is there a programmatic (e.g. ReST) interface to the converter? If not, let's do it! @Frederike, some further project informations can be found at www.spatialhumanities.de/ibr, our project website.

=== Zotero ===
Some TEI encoding project may need to use a "master bibliography" to group together all the bibliographic references that are used in a given text or collection of texts. Using the "masterfile" option in Oxygen give the user a convenient way of pointing to a reference without having to encode a ref each time it is used in a text or in a specific bibliographic section.
<pre>
<bibl type="fromStone">
<ptr target="#Breal1878"/>
<citedRange>15</citedRange>
</bibl>
</pre>

The bibliography can be inserted in a <back/> element with xinclude. But the question is how to use Zotero to create this file, update it and synchonize it with the biblographic masterfile.
Though incomplete, the workflow I use works like that :
* the entering of the bibliographic entries is done with zotero, in a group library
* the zotero database is then exported in xml using the "bibliontology_rdf" format (the TEI export format being to restrictive in its formatting choices : e.g. does'nt include "short titles" which are a requisite in epigraphy
* the bibliontology rdf is converted in TEI through XSLT in Oxygen (modifying existing xslt :https://github.com/paregorios/Zotero-RDF-to-TEI-XML)
* If the user wants to add a new reference in the masterbibliography or correct an entry, he or she has to do go to zotero and follow the whole workflow of export - tranform process. But the user might not have the user right to do so. And of course, there are some potential conflicting issues.

How to improve that workflow ? use a version control system like git or subversion ? or adding/modifying an entry in xml / tei and then updating the zotero group library via api ?

'''Comments:'''
--[[User:Elli Bleeker|Elli Bleeker]] 15:29, 1 July 2014 (CEST) It seems that working with subversion would improve the workflow a lot and at least illiminate the risk of conflicting issues. Of course users should have the right to work in the (seperate) xml file of the bibliographic masterfile and add/change references. Once completed, the xml file can be exported to Zotero. In short, this would mean a reverse of the current workflow.

=== Migrating value lists form CSS frameworks to ODD ===

The author mode of the Oxygen editor can be customized with custom css functions. A part from the function providing a more user-friendly and tag free visualization of the tei content, one of the fuction allow the user to edit attributes or simple elements values using combo boxes or check boxes. The "form controls" can display values collected from an xml schema. But these values can also be just in the oxygen css. This may be used in a workflow to test some choices before integrating them in a more consistent and persistant way in the ODD (then exported in the schema).

This could be useful in case you have user that may be ok to change the values in the css code but would be relunctant to get involved with the ODD editing / schema generation process.
cf. http://www.oxygenxml.com/doc/ug-editor/concepts/combo-box-editor.html#combo-box-editor

'''Comments:'''

--[[User:Raffaele.viglianti|Raffaele.viglianti]] 19:20, 16 June 2014 (CEST) This is interesting, would like to work on it. I would suggest to make it less tied to Oxygen and think in terms of CSS to ODD, for example to limit attribute values (e.g. hi[rend=italic])

[[User:Elena Spadini|Elena Spadini]] 00:13, 24 June 2014 (CEST) I'm not well-exeperienced with the author mode in oXygen and its customizations, but I would like to explore it working on this project.

=== Visualization of intertextual TEI content ===
[UPDATED on June 24th]

The focus is on the possibilities offered by TEI XML for encoding intertextuality. The case study concerns the personal library of an author and a digital edition of his work. The objective is to encode the material in such a way that the intertextual relations between the literary work and its external sources is visualized.

These -sometimes subtle- intertextual relationships provide insight into the nature of writing, all the more since the genesis of the literary work itself is already encoded in the edition (i.e. adds, dels, etc.). The envisioned result enables a user to study the writing process in detail as well as on a larger scale.

Material:
* detailed XML TEI transcription of the literary work concerned
* high quality digital facsimiles of the author's personal '''extant''' library
* rough transcriptions of the library books (based on OCR)

'''Comments:'''

* Clarification: is the project about the visualization? the relationships? More detail would be great.
*
--[[User:Elli Bleeker|Elli Bleeker]] 15:46, 1 July 2014 (CEST) The idea is to log the complete <nowiki>"path"</nowiki> of a citation: from a phrase underlined in a library book to the incorporation of that phrase in the author's work.
Currently, the intertextual references are encoded with [ref] tag in the XML TEI transcription of the literary work. The [ref]s refer to another xml file containing the transcriptions of the personal library. This file consists of [div]s, that contain anything from a complete library book to a small section (paragraph, phrase) from a library book.

The visualization of the intertextual relations comes in a later stage when transforming the documents. I wonder whether it is possible to change or improve this encoding.

=== Rendering Complex Markup ===
Rendering complex markup in an innovative and playful way: reconstructing & visualizing author’s
geographical position by the dates of sending of his letters (taking uncertainty into account)

'''Comments:'''

[[User:Magdalena Turska|Magdalena Turska]] 12:36, 12 June 2014 (CEST)

Starting with a list of letters that have a place and date of sending the idea would be to present map overview of the author's journeys.
See the simple Google Map at https://mapsengine.google.com/map/edit?mid=z3q4AefiR7Us.kf1fVBHlu8qE

Fist ideas re visualisation:
* places color-coded with color getting darker to represent 'later' places
* similarly shaded lines along the routes between places
* animation with slider to show circle moving along the routes, size of the circle getting bigger with the uncertainty

Input data:
each letter has assigned place name and 1+ time intervals (notBefore to not After)

--[[User:Frederike Neuber|Frederike Neuber]] 22:25, 24 June 2014 (CEST)
Would it be a problem to work on different material? @TEI-experts
I would like to visualize the provenance of medieval manuscripts on a map, so even if I do not work with letters, the task is partly the same (extracting date and time from the <teiHeader> and visualizing it on a map). Then our scopes separate: Magdalena wants to reconstruct the journey, I want to visualize the chronology of different mss on one map.

[[User:Thomas Kollatz|Thomas Kollatz]] 15:56, 1 July 2014 (CEST)
I agree with [[User:Frederike Neuber|Frederike Neuber]]: the task is the same in all projects, where a spatio-temporal visualization makes sense: Extract date and time from header - and visualize the chronology of date/time and place on a map and/or timeline
/TEI/teiHeader/fileDesc/sourceDesc/msDesc/history/origin

=== Adding a TEI mode to a web editor ===
Title says it all!

'''Comments:'''

--[[User:Raffaele.viglianti|Raffaele.viglianti]] 19:20, 16 June 2014 (CEST) How does the [http://wiki.tei-c.org/index.php/DH2014Hackathon-Projects#ACE-based_Web_editor Angles] proposal above sound?

=== Juxta Script support ===
Adding support for Bengali text to Juxta Commons

'''Comments:'''
* This is fairly narrow.
[[User:Thomas Kollatz|Thomas Kollatz]] 15:57, 1 July 2014 (CEST) If Bengali then Hebrew (Arabic … right-to-left), please

=== Visualization ===
The archive of early Caribbean texts and images is a fairly large project which will be heavily encoded (and a portion of texts will be encoded by July). I'd like to explore ways of using the TEI to visualize relations between and among texts and elements of texts.

'''Comments:'''

--[[User:Elli Bleeker|Elli Bleeker]] 16:19, 1 July 2014 (CEST) What is the status of this project? I am also interested in finding ways to visualize relations between texts, perhaps there are similarities?

=== Jewish Sepulchral Headstones DB ===

Given that all headstones can be clearly located,
and about 20.000 (of total 26.000) inscriptions are dated,
and to a large extend can be distinguished by gender,
and also by language usage (hebrew, german, german in Hebrew letters, …),
they lend themselves to mining the epidat corpus for specific data facets and try to visualize the results "in an innovative and playful way".
#A challenging research questions could be the search for and visualization of the differences in word usage and specific idiomatic
## between different locations,
## within different periods (based on one or several locations),
## between inscriptions for men and inscriptions for women,
## between hebrew and non-hebrew inscriptions …
#Even more challenging is the search for inscriptions with very similar text coverage. These are quite difficult to discover by a simple full text search. The inscriptions are usually rather short, and the filter to develop has to consider the differentiating elements – usually names and dates – in order to determine, whether two text are identical or not.

All necessary information to answer this questions is contained in the metadata <teiHeader> and data <text> of each single record.
example – spatial and temporal metadata (date, country/region code, geo-coordinates, Thesaurus of Getty Names or OSM ID)
<history>
<origin>
<date notBefore='1621-08-17'>1621-08-17</date>
<country type="ISO_3166" key="XA-DE-HH">
Germany
<region>Hamburg</region>
</country>
<settlement type='city' key='tgn:7012310'>
Hamburg-Altona, Königstraße
<geogName>
Jüdischer Friedhof
<geo decls="#WGS">53.549373 9.950545</geo>
</geogName>
</settlement>
</origin>
</history>
example – gender-specific metadata (given according to ISO 5218:2004)
<particDesc>
<listPerson>
<person xml:id="hha-3361-1" s x='1'>
<persName>Schmuel ben Jehuda</persName>
<event when='1621-08-17' type="dateofdeath">
<desc/>
</event>
</person>
</listPerson>
</particDesc>
example – language Usage metadata:
<langUsage>

<language ident='he' usage='100'>Hebrew</language>
</langUsage>

With respect for the TEI Hackathon I have (just) set up a website with very general information how to harvest epidat records:
http://www.steinheim-institut.de/cgi-bin/epidat?info=howtoharvest (to be continued …)
Over and beyond that it would make no great difficulty to provide a zip file with the data available for the workshop.

'''Comments:'''
[[User:Thomas Kollatz|Thomas Kollatz]] 16:05, 1 July 2014 (CEST) The TEI spam filter seems to dislike the person-attribute s_x (middle-letter e) … rather prudish, isn't it

'''Discussion'''

What commonalities to you see? What seems interesting? Anything to add?

--[[User:Frederike Neuber|Frederike Neuber]] 23:21, 24 June 2014 (CEST)
Two (even if very different) projects, "Jewish Sepulchral Headstones DB" and "Rendering complex mark up", are dealing with visualization of spatial and temporal metadata.

Three (again very different) projects, "Visualization of intertextual TEI content", "Semantic Connections for Epigraphic Documents" and "Jewish Sepulchral Headstones DB", are dealing with semantic connection and modelling of content (even if not all of them say it explicitly in the description).

--[[User:Elli Bleeker|Elli Bleeker]] 16:25, 1 July 2014 (CEST)
Add to that the visualization of textual relations in the early Caribbean texts archive.

--[[User:Felix Lange| Felix Lange]] 16:30 4 July 2014 (CEST) - That's sounds pretty interesting, I'm on board. The text-analysis ("mining") part seems pretty tough, though. How exactly should the content of different inscriptions be compared? Do you think about general word-frequency-statistics, that can populate a Word-Cloud? Or do you plan text comparison that is "semantic" in a certain sense?

=== Core Builder ===
Another possible tool to work on: https://github.com/raffazizzi/coreBuilder
It provides a simple web interface to create stand-off markup. TEI files can be open into multiple ACE editors and the user can click on elements with xml:ids to create references.
The current version creates <app> elements containing <rdg>s with pointers to the selected elements. It should be easy enough to make the elements user configurable so that the Core Builder can be used to put together <linkGrp>s or <timeline>s.
The tool is written in CoffeScript with a [http://backbonejs.org/ Backbone] framework. --[[User:Raffaele.viglianti|Raffaele.viglianti]] 19:07, 16 June 2014 (CEST)

--[[User:Elli Bleeker|Elli Bleeker]] 16:23, 1 July 2014 (CEST) From the sound of it, I think I would like to work on this project. Some more detail would be great.

Here's a demo of the current version. It's got a few bugs but should show the basic functionality. Pick a couple of sources, then click on any element with xml:id to create a selection. Click add to save it to the "core". https://dl.dropboxusercontent.com/u/2443674/coreBuilder/index.html --[[User:Raffaele.viglianti|Raffaele.viglianti]] 02:31, 3 July 2014 (CEST)

Setting up a Jenkins server

2014-07-02T11:18:29Z

Rahtz: /* Why would I want to create a Jenkins server? */

This page contains instructions and a script for setting up a Jenkins Continuous Integration Server for automated building of all of the TEI products.

== What is a Jenkins server? ==

Jenkins is a continuous integration server, a tool from modern software engineering. It's role is to notice whenever a change is made to the work-in-progress text of the TEI standard and perform a range of tasks, including building building each of the language variants and a number of tests. Jenkins catches a broad range of technical issues and complains very loudly about them to the users it thinks caused them.

When it detects a change (because someone has edited one of the source code files), it downloads the changes and starts building the codebase to create an updated version of the project, whatever that is. In the case of the TEI, there are seven different sub-projects, each of which is built separately: the OxGarage conversion server, the Roma schema-building tool, the TEI Stylesheets, an XSLT 1.0 version of the Stylesheets, TEI P5, TEI P5 Documentation (the Guidelines etc.), and some TEI P5 test cases. Some of these jobs depend on others -- for instance, all of the TEIP5-* projects are built using the stylesheets created from the Stylesheets project.

== Why would I want to create a Jenkins server? ==

A Jenkins server is useful to project administrators because it will automatically create new builds whenever the codebase changes, so the admins don't have to remember to do that themselves. It will also notify you when a build fails, perhaps because a recent change to the source contained an error. Programmers working on the codebase can use this feature to check the changes they have made to make sure they're OK, and roll them back if they don't work, without having to have a complete build environment set up on their own computers.

The TEI's main Jenkins server, in Oxford, is at [http://tei.it.ox.ac.uk/jenkins/ http://tei.it.ox.ac.uk/jenkins/]. There you can see the seven build targets and look at their status -- when they were last built, when the last build failure occurred, etc. The Humanities Computing and Media Centre at the University of Victoria also has a Jenkins server running at [http://teijenkins.hcmc.uvic.ca/ http://teijenkins.hcmc.uvic.ca/]. That server was built using the script below.

You might want to set up your own Jenkins server for a number of reasons:

*To add extra redundancy to the TEI project build process
*To add your own build targets for specific purposes
*To learn about Jenkins so that you can help administer one of the main servers

== How do I go about creating a Jenkins server? ==

There are four stages:

1. Build a basic headless Ubuntu server, using the Ubuntu Precise 12.04 (Long-Term Support) edition.

2. Install an Oxygen licence in the right location (some of the TEI projects require Oxygen).

3. Run our customization script to install all of the TEI and Jenkins code.

4. Make some final tweaks to your setup (setting up security for Jenkins).

You will need to be comfortable with installing Linux and doing a couple of things at the command line. If you've never done this kind of thing before, this project is probably not for you.

Please note that the script is long and quite complicated, and it depends upon a variety of external services which may perhaps not be functioning correctly at the time when you run it. As a result, the script may fail. This is not really disastrous; you can open it in a text editor to see what it does, and run each command manually until the setup is complete. The script is intended as much to be a thorough documentation of how the TEI Jenkins servers work, and what is required in order to set one up, as it is to be a functional build script (although it has been thoroughly tested, and it does work).

== Stage one ==

Download the latest distribution of the Ubuntu Precise (12.04) server ISO from the Ubuntu download site ([http://www.ubuntu.com/download/ubuntu/alternative-download http://www.ubuntu.com/download/ubuntu/alternative-download]).

Install the distribution on the machine you're going to use as your server (or on a virtual machine, if you don't have a piece of hardware to dedicate to the job). Choose "Internet server" when you're asked what type of computer you're setting up, during the install process. Then do all the updates to make sure your Precise installation is fully updated.

== Stage two ==

Log into your server, and place a copy of a valid Oxygen license file, licensekey.txt, in /usr/share/oxygen/. The file should contain the nine lines of text of the Oxygen license key (located between the license key start and end markers). A valid Oxygen license is required in order to build some of the TEI projects.

== Stage three ==

Download our [https://sourceforge.net/p/tei/code/HEAD/tree/trunk/Documents/Editing/Jenkins/jenkins_builder_script_2012.sh Jenkins_builder_script.sh] script from the TEI SourceForge repository. Get the script onto your server somehow. Make it executable, and run it as root. You'll see some basic explanatory information as it starts up. When the script completes, you should have a working Jenkins machine. The Jenkins GUI will be running on its default port of 8080, and if you connect to your server on that port, you should see it start to run the first of the seven TEI jobs. The first run takes a long time, because it has to download all the source code from SVN, but subsequent builds triggered by changes should be much quicker.

== Stage four ==

Next, you need to set up some security for your Jenkins installation, by using the Jenkins management interface on port 8080 There are various ways to do this, using different authentication methods, but this is the simplest:

* Click on Manage Jenkins, then Configure System.
* Check "Enable security".
* Choose "Jenkins's own user database".
* Choose "Matrix-based security".
* Create a new user (called, for instance, "tei"), and give it full privileges (check everything for that user).
* For the Anonymous user, check only the Read boxes in Overall and Job.
* Click on Save at the bottom of the page to save your changes.

Now log in as the new user ("tei") and set a password for yourself. Now anyone can see the progress of jobs, but only the tei user can log in and make changes.

== What does your script actually do? ==

Basically, the builder script adds some repositories and installs some software from them, including the Jenkins server software. Then it downloads some configuration files from the TEI SourceForge repository, tweaks them a bit, and restarts Jenkins. You can read the script itself in the [https://sourceforge.net/p/tei/code/HEAD/tree/trunk/Documents/Editing/Jenkins/jenkins_builder_script_2012.sh SVN repository].

Setting up a Jenkins server

2014-07-02T11:18:09Z

Rahtz: /* Why would I want to create a Jenkins server? */

This page contains instructions and a script for setting up a Jenkins Continuous Integration Server for automated building of all of the TEI products.

== What is a Jenkins server? ==

Jenkins is a continuous integration server, a tool from modern software engineering. It's role is to notice whenever a change is made to the work-in-progress text of the TEI standard and perform a range of tasks, including building building each of the language variants and a number of tests. Jenkins catches a broad range of technical issues and complains very loudly about them to the users it thinks caused them.

When it detects a change (because someone has edited one of the source code files), it downloads the changes and starts building the codebase to create an updated version of the project, whatever that is. In the case of the TEI, there are seven different sub-projects, each of which is built separately: the OxGarage conversion server, the Roma schema-building tool, the TEI Stylesheets, an XSLT 1.0 version of the Stylesheets, TEI P5, TEI P5 Documentation (the Guidelines etc.), and some TEI P5 test cases. Some of these jobs depend on others -- for instance, all of the TEIP5-* projects are built using the stylesheets created from the Stylesheets project.

== Why would I want to create a Jenkins server? ==

A Jenkins server is useful to project administrators because it will automatically create new builds whenever the codebase changes, so the admins don't have to remember to do that themselves. It will also notify you when a build fails, perhaps because a recent change to the source contained an error. Programmers working on the codebase can use this feature to check the changes they have made to make sure they're OK, and roll them back if they don't work, without having to have a complete build environment set up on their own computers.

The TEI's main Jenkins server, in Oxford, is at [http://tei.it.ox.ac.uk/jenkins/ http://tei.oucs.ox.ac.uk/jenkins/]. There you can see the seven build targets and look at their status -- when they were last built, when the last build failure occurred, etc. The Humanities Computing and Media Centre at the University of Victoria also has a Jenkins server running at [http://teijenkins.hcmc.uvic.ca/ http://teijenkins.hcmc.uvic.ca/]. That server was built using the script below.

You might want to set up your own Jenkins server for a number of reasons:

*To add extra redundancy to the TEI project build process
*To add your own build targets for specific purposes
*To learn about Jenkins so that you can help administer one of the main servers

== How do I go about creating a Jenkins server? ==

There are four stages:

1. Build a basic headless Ubuntu server, using the Ubuntu Precise 12.04 (Long-Term Support) edition.

2. Install an Oxygen licence in the right location (some of the TEI projects require Oxygen).

3. Run our customization script to install all of the TEI and Jenkins code.

4. Make some final tweaks to your setup (setting up security for Jenkins).

You will need to be comfortable with installing Linux and doing a couple of things at the command line. If you've never done this kind of thing before, this project is probably not for you.

Please note that the script is long and quite complicated, and it depends upon a variety of external services which may perhaps not be functioning correctly at the time when you run it. As a result, the script may fail. This is not really disastrous; you can open it in a text editor to see what it does, and run each command manually until the setup is complete. The script is intended as much to be a thorough documentation of how the TEI Jenkins servers work, and what is required in order to set one up, as it is to be a functional build script (although it has been thoroughly tested, and it does work).

== Stage one ==

Download the latest distribution of the Ubuntu Precise (12.04) server ISO from the Ubuntu download site ([http://www.ubuntu.com/download/ubuntu/alternative-download http://www.ubuntu.com/download/ubuntu/alternative-download]).

Install the distribution on the machine you're going to use as your server (or on a virtual machine, if you don't have a piece of hardware to dedicate to the job). Choose "Internet server" when you're asked what type of computer you're setting up, during the install process. Then do all the updates to make sure your Precise installation is fully updated.

== Stage two ==

Log into your server, and place a copy of a valid Oxygen license file, licensekey.txt, in /usr/share/oxygen/. The file should contain the nine lines of text of the Oxygen license key (located between the license key start and end markers). A valid Oxygen license is required in order to build some of the TEI projects.

== Stage three ==

Download our [https://sourceforge.net/p/tei/code/HEAD/tree/trunk/Documents/Editing/Jenkins/jenkins_builder_script_2012.sh Jenkins_builder_script.sh] script from the TEI SourceForge repository. Get the script onto your server somehow. Make it executable, and run it as root. You'll see some basic explanatory information as it starts up. When the script completes, you should have a working Jenkins machine. The Jenkins GUI will be running on its default port of 8080, and if you connect to your server on that port, you should see it start to run the first of the seven TEI jobs. The first run takes a long time, because it has to download all the source code from SVN, but subsequent builds triggered by changes should be much quicker.

== Stage four ==

Next, you need to set up some security for your Jenkins installation, by using the Jenkins management interface on port 8080 There are various ways to do this, using different authentication methods, but this is the simplest:

* Click on Manage Jenkins, then Configure System.
* Check "Enable security".
* Choose "Jenkins's own user database".
* Choose "Matrix-based security".
* Create a new user (called, for instance, "tei"), and give it full privileges (check everything for that user).
* For the Anonymous user, check only the Read boxes in Overall and Job.
* Click on Save at the bottom of the page to save your changes.

Now log in as the new user ("tei") and set a password for yourself. Now anyone can see the progress of jobs, but only the tei user can log in and make changes.

== What does your script actually do? ==

Basically, the builder script adds some repositories and installs some software from them, including the Jenkins server software. Then it downloads some configuration files from the TEI SourceForge repository, tweaks them a bit, and restarts Jenkins. You can read the script itself in the [https://sourceforge.net/p/tei/code/HEAD/tree/trunk/Documents/Editing/Jenkins/jenkins_builder_script_2012.sh SVN repository].

OxGarage

2014-04-24T20:30:09Z

Rahtz: /* Synopsis */

[[Category:Tools]]

[[Category:Conversion and preprocessing tools]]

== Synopsis ==
[http://www.oucs.ox.ac.uk/oxgarage/ OxGarage] is a web, and RESTful, service to manage the transformation of documents between a variety of formats. The majority of transformations use the Text Encoding Initiative format as a pivot format. It is a good tool for conversion from TEI to Word (.docx), or Word (.docx) to TEI, but also does many other formats.

There is a [http://htmlpreview.github.io/?https://github.com/sebastianrahtz/oxgarage/blob/master/doc/matrix.html list of formats for conversion to and from] which OxGarage supports.
Some of these use [[Tei-xsl|XSLT-based transformations]] and others are provided by [http://www.artofsolving.com/opensource/jodconverter JODConverter].

== Features ==

OxGarage can be used to
* Convert TEI documents to HTML, LaTeX, Word, OpenOffice, and ePub
* Process TEI ODD documents to make schemas or documentation
* Convert Word documents to TEI
* Transform some common XML formats (NLM, P4, Docbook) to or from TEI
* Manage any of the document conversions supported by OpenOffice

A user uploads a document, chooses the target format, OxGarage works out the pipeline of required transformation steps, performs them, and returns the resulting new document. For example, an ODD document can be turned into ePub by

# expanding the ODD file by merging with the TEI P5 source
# converting the resulting XML to TEI Lite for formatting
# transforming TEI Lite XML to HTML and packaging as ePub

OxGarage takes care of all three stages, the user does not need to know about the middle stage. All transformations using TEI are
performed with XSLT 2.0 stylesheets, some other transformations use JODConverter and a headless OpenOffice instance.

The results for some transformations can be tweaked by choosing different output profiles. These are defined on the OxGarage server.

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

== System requirements ==
A standard modern web browser is all that is required to make use of the Web Client. If you want to deploy the underlying system yourself you need Sun/Oracle Java 6 JRE, Tomcat, OpenOffice, etc. To build it you also need Maven and various java libraries, and a Debian setup is provided. For more information see https://github.com/sebastianrahtz/oxgarage

== Source code and licensing ==
OxGarage source code is hosted on Github, at https://github.com/sebastianrahtz/oxgarage;
is is a fork and extension of the EGE project (on Sourceforge: http://enrich-ege.sourceforge.net/)
and is licensed under the GPL.

== Support for TEI ==
The basic stylesheets provided with OxGarage (and ENRICH-EGE) use TEI as an output and pivot format.

== Language(s) ==
The Web Client and Documentation is only provided in English

== Documentation ==
See doc directory at https://github.com/sebastianrahtz/oxgarage

== Tech support ==

Contact oxgarage@oucs.ox.ac.uk for best-effort support concerning the OxGarage customisation.

== User community ==

== Sample implementations ==

* http://www.tei-c.org/oxgarage/ -- This production version sometimes uses an older release of the software.
* http://oxgarage.oucs.ox.ac.uk:8080/ege-webclient/ -- This development version is more likely to have bugs in it.

== Current version number and date of release ==

Version 2.3.3 March 2014

== History of versions ==

== How to download or buy ==

Download either:
* from Github (https://github.com/sebastianrahtz/oxgarage)
* as a Debian package from http://tei.oucs.ox.ac.uk/teideb/

== Additional notes ==

== References ==

<references/>

OxGarage

2014-04-24T20:23:23Z

Rahtz: /* Current version number and date of release */

[[Category:Tools]]

[[Category:Conversion and preprocessing tools]]

== Synopsis ==
[http://www.oucs.ox.ac.uk/oxgarage/ OxGarage] is a web, and RESTful, service to manage the transformation of documents between a variety of formats. The majority of transformations use the Text Encoding Initiative format as a pivot format. It is a good tool for conversion from TEI to Word (.docx), or Word (.docx) to TEI, but also does many other formats.

There is a [http://www.oucs.ox.ac.uk/oxgarage/matrix.xml list of formats for conversion to and from] which OxGarage supports.
Some of these use [[Tei-xsl|XSLT-based transformations]] and others are provided by [http://www.artofsolving.com/opensource/jodconverter JODConverter].

== Features ==

OxGarage can be used to
* Convert TEI documents to HTML, LaTeX, Word, OpenOffice, and ePub
* Process TEI ODD documents to make schemas or documentation
* Convert Word documents to TEI
* Transform some common XML formats (NLM, P4, Docbook) to or from TEI
* Manage any of the document conversions supported by OpenOffice

A user uploads a document, chooses the target format, OxGarage works out the pipeline of required transformation steps, performs them, and returns the resulting new document. For example, an ODD document can be turned into ePub by

# expanding the ODD file by merging with the TEI P5 source
# converting the resulting XML to TEI Lite for formatting
# transforming TEI Lite XML to HTML and packaging as ePub

OxGarage takes care of all three stages, the user does not need to know about the middle stage. All transformations using TEI are
performed with XSLT 2.0 stylesheets, some other transformations use JODConverter and a headless OpenOffice instance.

The results for some transformations can be tweaked by choosing different output profiles. These are defined on the OxGarage server.

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

== System requirements ==
A standard modern web browser is all that is required to make use of the Web Client. If you want to deploy the underlying system yourself you need Sun/Oracle Java 6 JRE, Tomcat, OpenOffice, etc. To build it you also need Maven and various java libraries, and a Debian setup is provided. For more information see https://github.com/sebastianrahtz/oxgarage

== Source code and licensing ==
OxGarage source code is hosted on Github, at https://github.com/sebastianrahtz/oxgarage;
is is a fork and extension of the EGE project (on Sourceforge: http://enrich-ege.sourceforge.net/)
and is licensed under the GPL.

== Support for TEI ==
The basic stylesheets provided with OxGarage (and ENRICH-EGE) use TEI as an output and pivot format.

== Language(s) ==
The Web Client and Documentation is only provided in English

== Documentation ==
See doc directory at https://github.com/sebastianrahtz/oxgarage

== Tech support ==

Contact oxgarage@oucs.ox.ac.uk for best-effort support concerning the OxGarage customisation.

== User community ==

== Sample implementations ==

* http://www.tei-c.org/oxgarage/ -- This production version sometimes uses an older release of the software.
* http://oxgarage.oucs.ox.ac.uk:8080/ege-webclient/ -- This development version is more likely to have bugs in it.

== Current version number and date of release ==

Version 2.3.3 March 2014

== History of versions ==

== How to download or buy ==

Download either:
* from Github (https://github.com/sebastianrahtz/oxgarage)
* as a Debian package from http://tei.oucs.ox.ac.uk/teideb/

== Additional notes ==

== References ==

<references/>

OxGarage

2014-04-24T20:22:54Z

Rahtz: /* Documentation */

[[Category:Tools]]

[[Category:Conversion and preprocessing tools]]

== Synopsis ==
[http://www.oucs.ox.ac.uk/oxgarage/ OxGarage] is a web, and RESTful, service to manage the transformation of documents between a variety of formats. The majority of transformations use the Text Encoding Initiative format as a pivot format. It is a good tool for conversion from TEI to Word (.docx), or Word (.docx) to TEI, but also does many other formats.

There is a [http://www.oucs.ox.ac.uk/oxgarage/matrix.xml list of formats for conversion to and from] which OxGarage supports.
Some of these use [[Tei-xsl|XSLT-based transformations]] and others are provided by [http://www.artofsolving.com/opensource/jodconverter JODConverter].

== Features ==

OxGarage can be used to
* Convert TEI documents to HTML, LaTeX, Word, OpenOffice, and ePub
* Process TEI ODD documents to make schemas or documentation
* Convert Word documents to TEI
* Transform some common XML formats (NLM, P4, Docbook) to or from TEI
* Manage any of the document conversions supported by OpenOffice

A user uploads a document, chooses the target format, OxGarage works out the pipeline of required transformation steps, performs them, and returns the resulting new document. For example, an ODD document can be turned into ePub by

# expanding the ODD file by merging with the TEI P5 source
# converting the resulting XML to TEI Lite for formatting
# transforming TEI Lite XML to HTML and packaging as ePub

OxGarage takes care of all three stages, the user does not need to know about the middle stage. All transformations using TEI are
performed with XSLT 2.0 stylesheets, some other transformations use JODConverter and a headless OpenOffice instance.

The results for some transformations can be tweaked by choosing different output profiles. These are defined on the OxGarage server.

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

== System requirements ==
A standard modern web browser is all that is required to make use of the Web Client. If you want to deploy the underlying system yourself you need Sun/Oracle Java 6 JRE, Tomcat, OpenOffice, etc. To build it you also need Maven and various java libraries, and a Debian setup is provided. For more information see https://github.com/sebastianrahtz/oxgarage

== Source code and licensing ==
OxGarage source code is hosted on Github, at https://github.com/sebastianrahtz/oxgarage;
is is a fork and extension of the EGE project (on Sourceforge: http://enrich-ege.sourceforge.net/)
and is licensed under the GPL.

== Support for TEI ==
The basic stylesheets provided with OxGarage (and ENRICH-EGE) use TEI as an output and pivot format.

== Language(s) ==
The Web Client and Documentation is only provided in English

== Documentation ==
See doc directory at https://github.com/sebastianrahtz/oxgarage

== Tech support ==

Contact oxgarage@oucs.ox.ac.uk for best-effort support concerning the OxGarage customisation.

== User community ==

== Sample implementations ==

* http://www.tei-c.org/oxgarage/ -- This production version sometimes uses an older release of the software.
* http://oxgarage.oucs.ox.ac.uk:8080/ege-webclient/ -- This development version is more likely to have bugs in it.

== Current version number and date of release ==

Version 2.1.2 June 2013

== History of versions ==

== How to download or buy ==

Download either:
* from Github (https://github.com/sebastianrahtz/oxgarage)
* as a Debian package from http://tei.oucs.ox.ac.uk/teideb/

== Additional notes ==

== References ==

<references/>

OxGarage

2014-04-24T20:22:31Z

Rahtz: /* System requirements */

[[Category:Tools]]

[[Category:Conversion and preprocessing tools]]

== Synopsis ==
[http://www.oucs.ox.ac.uk/oxgarage/ OxGarage] is a web, and RESTful, service to manage the transformation of documents between a variety of formats. The majority of transformations use the Text Encoding Initiative format as a pivot format. It is a good tool for conversion from TEI to Word (.docx), or Word (.docx) to TEI, but also does many other formats.

There is a [http://www.oucs.ox.ac.uk/oxgarage/matrix.xml list of formats for conversion to and from] which OxGarage supports.
Some of these use [[Tei-xsl|XSLT-based transformations]] and others are provided by [http://www.artofsolving.com/opensource/jodconverter JODConverter].

== Features ==

OxGarage can be used to
* Convert TEI documents to HTML, LaTeX, Word, OpenOffice, and ePub
* Process TEI ODD documents to make schemas or documentation
* Convert Word documents to TEI
* Transform some common XML formats (NLM, P4, Docbook) to or from TEI
* Manage any of the document conversions supported by OpenOffice

A user uploads a document, chooses the target format, OxGarage works out the pipeline of required transformation steps, performs them, and returns the resulting new document. For example, an ODD document can be turned into ePub by

# expanding the ODD file by merging with the TEI P5 source
# converting the resulting XML to TEI Lite for formatting
# transforming TEI Lite XML to HTML and packaging as ePub

OxGarage takes care of all three stages, the user does not need to know about the middle stage. All transformations using TEI are
performed with XSLT 2.0 stylesheets, some other transformations use JODConverter and a headless OpenOffice instance.

The results for some transformations can be tweaked by choosing different output profiles. These are defined on the OxGarage server.

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

== System requirements ==
A standard modern web browser is all that is required to make use of the Web Client. If you want to deploy the underlying system yourself you need Sun/Oracle Java 6 JRE, Tomcat, OpenOffice, etc. To build it you also need Maven and various java libraries, and a Debian setup is provided. For more information see https://github.com/sebastianrahtz/oxgarage

== Source code and licensing ==
OxGarage source code is hosted on Github, at https://github.com/sebastianrahtz/oxgarage;
is is a fork and extension of the EGE project (on Sourceforge: http://enrich-ege.sourceforge.net/)
and is licensed under the GPL.

== Support for TEI ==
The basic stylesheets provided with OxGarage (and ENRICH-EGE) use TEI as an output and pivot format.

== Language(s) ==
The Web Client and Documentation is only provided in English

== Documentation ==
See links at http://www.oucs.ox.ac.uk/oxgarage/ and http://enrich-ege.sourceforge.net/

== Tech support ==

Contact oxgarage@oucs.ox.ac.uk for best-effort support concerning the OxGarage customisation.

== User community ==

== Sample implementations ==

* http://www.tei-c.org/oxgarage/ -- This production version sometimes uses an older release of the software.
* http://oxgarage.oucs.ox.ac.uk:8080/ege-webclient/ -- This development version is more likely to have bugs in it.

== Current version number and date of release ==

Version 2.1.2 June 2013

== History of versions ==

== How to download or buy ==

Download either:
* from Github (https://github.com/sebastianrahtz/oxgarage)
* as a Debian package from http://tei.oucs.ox.ac.uk/teideb/

== Additional notes ==

== References ==

<references/>

Oxford2013-Actions2

2014-03-07T14:14:25Z

Rahtz: /* Actions for Sebastian Rahtz */

==Council Actions from November 2013 Oxford Meeting==

A list of actions, those responsible, and what has been done about them from [http://www.tei-c.org/Activities/Council/Meetings/tcm56.xml Oxford 2013 face to face meeting] of TEI Technical Council

===Actions for Brett Barney===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|Attributes without examples

|BB, RW
|BB and RW to turn into bug reports those attributes that are without examples that are high priority or need new/updated definitions.
|
|-
|[https://sourceforge.net/p/tei/bugs/563/ BUG 563] inconsistent encoding of citations to sources of examples (AMBER open). Working group recommends ass...
|BB, EM, PS
|BB, EM, and PS to work on the ticket by mid-February 2014.
|
|-
|[https://sourceforge.net/p/tei/bugs/610/ BUG 610] "lem" used in a confusing way in CriticalApparatus.xml (AMBER open). Action: BB to remove the last c...
|BB
|BB to remove the last clause of the sentence in question, beginning ", or to make clear".
|Done 2013-11-13
|-
|[https://sourceforge.net/p/tei/bugs/387/ BUG 387] clarifying heading or title of a graphic (GREEN open). LB recently posted a comment approving of the...
|BB
|BB will implement the ticket.
|Done 2013-11-13
|}

===Actions for Lou Burnard===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|[https://sourceforge.net/p/tei/feature-requests/457/ FR 457] : KH: In the ticket I want to clarify what you use tagUsage for and what to put in a project-specifi...
|KH, LB, JC
|KH, LB, and JC will review and make a recommendation to Council before the next face-to-face.
|KH emailed the others on 2013-12-26; LB updated ticket and emailed the others 2014-01-05
|-
|[https://sourceforge.net/p/tei/feature-requests/453/ FR 453] a place for metadata that you can't fit into existing header elements AMBER open Discussion talks mo...
|MH, PS, LB
|MH will offer DC examples and PS will offer MARC examples. LB will pull them together into some text to be inserted into the Guidelines. Given this, Council will reconsider the feature request and whether to create the wrapper element.
|Added comment on ticket suggesting that the proposal seems doomed to be rejected; action to explain how to handle this situation in the Guidelines remains open.
|-
|[https://sourceforge.net/p/tei/feature-requests/471/ FR 471] extend the possible usages of argument (AMBER open). (If the intended use case is encoder-supplied a...
|LB, MH
|New element <abstract> added; examples added .
|Done 2013-11-12
|-
|Pure ODD

|LB
|LB to add the new elements and the documentation ahead of the next release; documentation need only be at the element level, along with some brief introduction in the Guidelines, to be expanded to a full section later.
|First pass completed 2013-12-01
|-
|[https://sourceforge.net/p/tei/feature-requests/443/ FR 443] @resp should be a member of att.global AMBER open. JC and SR: Global attributes should really not be...
|MH, LB
|MH and LB to agree on clarification to Guidelines to say that @resp means different things: responsibility for markup and content except when the element in question is a transcriptional element, in which case the content of the element is marked as coming from the source.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/366/ FR 366] rationalize content models of org and place (etc) (AMBER open). Group thinks a small group of people...
|JC, LB, SB
|JC to make ticket red, should stay with JC, and he should initiate the process, working with LB and SB.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/458/ FR 458] Make listBibl and model.biblLike member of model.personPart (AMBER open). Lou has already done items...
|LB
|close the ticket.
|Done
|-
|i18n: take forward updating translations

|LB
|LB to testdrive the spreadsheet.
|Done
|-
|[https://sourceforge.net/p/tei/feature-requests/482/ FR 482] The term strikes back - terminology chapter (AMBER open). The ISO is working on a standard for termi...
|LB, KH, SB
|LB, KH and SB to articulate a more generic policy for TEI on the integration of external standards and will generate a one-page proposal for this policy. This should be provided to Council ahead of the next teleconference. In addition, LB, KH, and SB will check with Laurent that he wants TBX incorporated into the Guidelines as is or kept in sync in the future and what he thinks about melding into the rest of the TEI Guidelines (in language, approach, element naming conventions) or keeping it self-contained.
|Kevin drafted a [http://www.tei-c.org/Activities/Council/Working/tcw28.xml generic policy] and circulated to Lou and Syd on 2013-12-26. Discussion of whether to incorporate TBX into the Guidelines is [http://sourceforge.net/p/tei/feature-requests/482/#28f3 happening on ticket].
|-
|[https://sourceforge.net/p/tei/feature-requests/480/ FR 480] Adding the @hand attribute to all (or most) text-containing elements (AMBER open). Breakout group wa...
|LB
|LB to respond to the ticket FR 480.
|
|-
|[http://wiki.tei-c.org/index.php/Text_Directionality_Draft first draft of new Guidelines sections] and questions [MH] MH summarized the genesis of this text from Providence. He noted that not only th...
|MH, LB
|Entire Council to (re)read MH’s draft before next face-to-face meeting. Once we’ve done that and agreed, someone will rewrite chapter 5 (WD) to include MH’s draft and the current section 10.6.6. LB volunteered.
|
|-
|[https://sourceforge.net/p/tei/bugs/548/ BUG 548] use of modal verbs in Guidelines (AMBER pending-later). Already assigned to KH. RW agreed to help. I...
|KH, RW, LB
|KH and RW to create a new, detailed ticket with all questionable cases. In the meantime, LB will fix the edits that KH made at r12525.
|Commented out otiose paragraph.
|-
|[https://sourceforge.net/p/tei/bugs/468/ BUG 468] Order of elements in publicationStmt (AMBER open-accepted). Group discussion: SB: Despite Lou’s comm...
|SB, LB
|SB will do the content model and LB will do the prose. They’ll work out the specifics.
|Emailed syd 2014-01-05
|-
|[https://sourceforge.net/p/tei/feature-requests/469/ FR 469] add extent to att.dimensions (GREEN open). Agreed. Action: LB to provide an example in HD chapter (2...
|LB
|LB to provide an example in HD chapter (2.2.3) and close ticket.
|Done 2013-11-20
|-
|[https://sourceforge.net/p/tei/bugs/605/ BUG 605] clarifying add vs. supplied and del vs. surplus (AMBER open). Action: HC to emend the prose of the p...
|HC, LB
|HC to emend the prose of the paragraph beginning "The add element should not be used" to reference the surplus element also; LB points out that the specList can't be modified, because supplied/surplus aren't defined in Core.
|Done, I think.
|-
|[https://sourceforge.net/p/tei/bugs/609/ BUG 609] "lemma" used in a confusing way in CriticalApparatus.xml (AMBER open). Action: LB to remove the phra...
|LB
|LB to remove the phrase "on any one lemma" from the @varSeq description.
|Done, 2013-11-13
|-
|[https://sourceforge.net/p/tei/feature-requests/461/ FR 461] Two small improvements to `recording` (GREEN open). Action: LB to do this by next teleconference....
|LB
|LB to do this by next teleconference.
|Done 2013-11-13
|-
|[https://sourceforge.net/p/tei/feature-requests/482/ FR 482] Earlier we decided:Action: LB, KH and SB to articulate a more generic policy for TEI on the integrat...
|LB, KH, SB
|LB, KH and SB to articulate a more generic policy for TEI on the integration of external standards and will generate a one-page proposal for this policy. This should be provided to Council ahead of the next teleconference. In addition, LB, KH, and SB will check with Laurent that he wants TBX incorporated into the Guidelines as is or kept in sync in the future and what he thinks about melding into the rest of the TEI Guidelines (in language, approach, element naming conventions) or keeping it self-contained.
|Kevin drafted a [http://www.tei-c.org/Activities/Council/Working/tcw28.xml generic policy] and circulated to Lou and Syd on 2013-12-26. Discussion of whether to incorporate TBX into the Guidelines is [http://sourceforge.net/p/tei/feature-requests/482/#28f3 happening on ticket].
|-
|Correspondence SIG:

|SB, LB
|SB and LB would like to (re?-)join the task force. Council advises them to keep in mind the work by the Ontology/MS SIGs, in particular Torsten Schassan, on an ‘object’ or ‘objectDesc’ element.
|
|}

===Actions for Syd Bauman===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|[https://sourceforge.net/p/tei/feature-requests/384/ FR 384] : In April RW made a spreadsheet showing which elements she recommends moving into att.typed. And in...
|SB, RW
|SB and RW will review the list again.
|SB sent e-mail to RW 2013-12-06, no response yet (2014-01-10); pinged again 2014-02-04.
|-
|[https://sourceforge.net/p/tei/feature-requests/459/ FR 459] : This is just waiting for implementation....
|SB
|SB will implement by end of January 2014.
|SB: if I understand ticket correctly, this was done along w/ 486.
|-
|[https://sourceforge.net/p/tei/feature-requests/481/ FR 481] check that all sibling att.translatable elements have @versionDate (AMBER open). (Agreed that siblin...
|SB
|SB to check whether this is implemented, and if not, get it implemented then close the ticket.
|has now been implemented (twice, sort of); ticket closed
|-
|[https://sourceforge.net/p/tei/feature-requests/468/ FR 468] : HC: precision expresses false precision that’s not real probability. It’s something more like cert...
|SB
|
|SB: when I checked this had already been done -- HC in r12606
|-
|[https://sourceforge.net/p/tei/feature-requests/383/ FR 383] where to put idno within biblStruct? (AMBER open) This is one of three tickets where KH could not fi...
|KH, SB
|KH will create a new ticket pointing to this and the other two tickets with deprecation problems (as listed on the wiki) saying we need a way to deprecate members of content model and reassign to SB to solve the three tickets using a Schematron warning, and to add @validUntil on constraintSpec.
|This ticket reassigned to Syd, and new ticket created: https://sourceforge.net/p/tei/feature-requests/486/ .
|-
|[https://sourceforge.net/p/tei/feature-requests/366/ FR 366] rationalize content models of org and place (etc) (AMBER open). Group thinks a small group of people...
|JC, LB, SB
|JC to make ticket red, should stay with JC, and he should initiate the process, working with LB and SB.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/482/ FR 482] The term strikes back - terminology chapter (AMBER open). The ISO is working on a standard for termi...
|LB, KH, SB
|LB, KH and SB to articulate a more generic policy for TEI on the integration of external standards and will generate a one-page proposal for this policy. This should be provided to Council ahead of the next teleconference. In addition, LB, KH, and SB will check with Laurent that he wants TBX incorporated into the Guidelines as is or kept in sync in the future and what he thinks about melding into the rest of the TEI Guidelines (in language, approach, element naming conventions) or keeping it self-contained.
|Kevin drafted a [http://www.tei-c.org/Activities/Council/Working/tcw28.xml generic policy] and circulated to Lou and Syd on 2013-12-26. Discussion of whether to incorporate TBX into the Guidelines is [http://sourceforge.net/p/tei/feature-requests/482/#28f3 happening on ticket].
|-
|[https://sourceforge.net/p/tei/bugs/276/ BUG 276] internationalisation links (AMBER open). Language links at bottom of a page should take you to same ...
|JC, SB
|JC to make Green and allocate to SB.
|
|-
|[https://sourceforge.net/p/tei/bugs/619/ BUG 619] tei_allPlus.rng: conflicting ID-types for attribute "id" of element "partialdiff" from namespace "ht...
|SB
|SB to double-check whether able to reproduce and report back on ticket if able to.
|DONE. Tried both with Options > Preferences > XML > XML Parser > RELAX NG > Check ID/IDREF checked and unchecked against tei_allPlus.rng 2.5.0, and did not reproduce error.
|-
|[https://sourceforge.net/p/tei/bugs/288/ BUG 288] deprecate use of gram except as a child of gramGrp (AMBER open-accepted). [This is pending creation ...
|SB
|SB to create the new ticket and write the Schematron for this particular deprecation.
|Elsewhere we decided that KH would create the new ticket, which he's done at https://sourceforge.net/p/tei/feature-requests/486/ . But SB still needs to solve this ticket.
|-
|[https://sourceforge.net/p/tei/bugs/468/ BUG 468] Order of elements in publicationStmt (AMBER open-accepted). Group discussion: SB: Despite Lou’s comm...
|SB, LB
|SB will do the content model and LB will do the prose. They’ll work out the specifics.
|Content model checked-in w/ typo at r12736, fixed in r12748.
|-
|[https://sourceforge.net/p/tei/bugs/405/ BUG 405] XPointer schemes may not nest, but see ch. 16 (AMBER open). Action: SB to fix documentation....
|SB
|SB to fix documentation.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/482/ FR 482] Earlier we decided:Action: LB, KH and SB to articulate a more generic policy for TEI on the integrat...
|LB, KH, SB
|LB, KH and SB to articulate a more generic policy for TEI on the integration of external standards and will generate a one-page proposal for this policy. This should be provided to Council ahead of the next teleconference. In addition, LB, KH, and SB will check with Laurent that he wants TBX incorporated into the Guidelines as is or kept in sync in the future and what he thinks about melding into the rest of the TEI Guidelines (in language, approach, element naming conventions) or keeping it self-contained.
|Kevin drafted a [http://www.tei-c.org/Activities/Council/Working/tcw28.xml generic policy] and circulated to Lou and Syd on 2013-12-26. Discussion of whether to incorporate TBX into the Guidelines is [http://sourceforge.net/p/tei/feature-requests/482/#28f3 happening on ticket].
|-
|[http://sourceforge.net/p/tei/feature-requests/378/ FR 378] ; c.f. A Generic Formalism for Encoding Standoff annotations in TEI). Action: JC to ask Peter Stadle...
|JC, HC, SB
|JC to ask Peter Stadler if he’d like to attend as Council rep; otherwise any interested members of Council (HC,SB) are encouraged to attend virtually.
|
|-
|Correspondence SIG:

|SB, LB
|SB and LB would like to (re?-)join the task force. Council advises them to keep in mind the work by the Ontology/MS SIGs, in particular Torsten Schassan, on an ‘object’ or ‘objectDesc’ element.
|
|-
|[https://sourceforge.net/p/tei/bugs/525/ BUG 525] citedRange and biblScope should share att class (GREEN open). SB admitted to sloth. Action: SB to co...
|SB
|SB to complete.
|done, at r12767
|}

===Actions for Hugh Cayless===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|Report on specification and estimated cost for XPointer resolver [HC/SB]

|HC
|HC to report on XPointer resolver and whether we should progress it.
|Draft GLs revision posted on [http://hcayless.github.io/TEI-Guidelines/Guidelines-web/en/html/SA.html#SATS GitHub]
|-
|[https://sourceforge.net/p/tei/feature-requests/465/ FR 465] : Gabby and HC seem to agree on it, and the example looks sensible. LB’s comment could be raised as ...
|HC
|HC will implement before end of January 2014.
|Done.
|-
|[https://sourceforge.net/p/tei/feature-requests/384/ FR 384] that once 384 is implemented, we’ll add a note on att.typed reminding people that this is meant for ...
|HC, KH
|HC will implement [DONE]. KH will add a comment to FR 384 [DONE].
|done during Council meeting
|-
|[https://sourceforge.net/p/tei/feature-requests/462/ FR 462] idno@type='uri' for Linked Data AMBER open (We agreed. @type=”URI” alongside @type=”URL”) EM: The su...
|HC
|HC to implement this and close the ticket FR 462.
|Done.
|-
|[https://sourceforge.net/p/tei/feature-requests/468/ FR 468] : HC: precision expresses false precision that’s not real probability. It’s something more like cert...
|HC
|HC to email TEI-L.
|FR implemented at meeting and email sent. No agitated (or indeed, any) responses.
|-
|Ideas on how to run an experimental TEI Hackathon [SR]

|JC, HC, SR, EM
|JC to approach the DH 2014 committee and find out how they would prefer us to do it, and whether it’s a good idea; and tell the Board that HC, SR and EM are prepared to be involved in organizing this along with one or more Board members.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/212/ FR 212] Generic dating class (AMBER pending-accepted). Gabby claimed in 2011 that it’s done except needs som...
|HC, MH
|HC to investigate whether it’s actually been done. MH offered examples if needed.
|Gabby says the element/classSpecs were done, but corresponding prose was never added to the Guidelines. Opened a new bug [https://sourceforge.net/p/tei/bugs/635/ #635] to address that.
|-
|[https://sourceforge.net/p/tei/bugs/605/ BUG 605] clarifying add vs. supplied and del vs. surplus (AMBER open). Action: HC to emend the prose of the p...
|HC, LB
|HC to emend the prose of the paragraph beginning "The add element should not be used" to reference the surplus element also; LB points out that the specList can't be modified, because supplied/surplus aren't defined in Core.
|Done.
|-
|[http://sourceforge.net/p/tei/feature-requests/378/ FR 378] ; c.f. A Generic Formalism for Encoding Standoff annotations in TEI). Action: JC to ask Peter Stadle...
|JC, HC, SB
|JC to ask Peter Stadler if he’d like to attend as Council rep; otherwise any interested members of Council (HC,SB) are encouraged to attend virtually.
|
|}

===Actions for James Cummings===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|[https://sourceforge.net/p/tei/feature-requests/457/ FR 457] : KH: In the ticket I want to clarify what you use tagUsage for and what to put in a project-specifi...
|KH, LB, JC
|KH, LB, and JC will review and make a recommendation to Council before the next face-to-face.
|KH emailed the others on 2013-12-26.
|-
|[https://sourceforge.net/p/tei/feature-requests/476/ FR 476] use of stage inside poetry, and using placement attribute (AMBER open). (Council agreed to @place; s...
|JC
|JC to close ticket FR 476 noting it has been resolved.
|Done
|-
|[https://docs.google.com/document/d/1766WTJV2xcfANh8HRZW5m520yrC1nCzQJzUgKpwiylI/edit TEI Roma Replacement Specification] JC: The existing Roma is dated and flawed, as we all know. Many tickets have come up which we cannot...
|JC
|ALL Council to go through the proposal again and discuss it, remembering to look at the comments, and further refine it. JC to make sure it’s tidied up. Deadline: next teleconference.
|Not finished.
|-
|[https://sourceforge.net/p/tei/feature-requests/303/ FR 303] check the apache logs for frequent 404s (AMBER open). Action: JC to ask DS to make the TEI-C webserv...
|JC, MH
|JC to ask DS to make the TEI-C webserver logs available somewhere we can see them; then action on MH to write script to generate lists of bad links of various types. JC also to check google analytics/Webmaster tools. Deadline to report back by next conference call.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/305/ FR 305] Updating info on projects page (AMBER open). Project pages go out of date. There is a way to submit ...
|JC
|JC to ask DS to make that correction info available on each project page, along with its last-updated date if possible (and the latter should also show up on the bullet-point list).
|
|-
|[https://sourceforge.net/p/tei/feature-requests/466/ FR 466] Make it possible to add SIG labels to tickets (AMBER open). Action: JC as SIG Coordinator to tell th...
|JC
|JC as SIG Coordinator to tell the SIGs that if they wish, we can make their SIG convener a developer on SF and make it possible to assign SIG labels to tickets. Deadline: next teleconference.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/366/ FR 366] rationalize content models of org and place (etc) (AMBER open). Group thinks a small group of people...
|JC, LB, SB
|JC to make ticket red, should stay with JC, and he should initiate the process, working with LB and SB.
|
|-
|Ideas on how to run an experimental TEI Hackathon [SR]

|JC, HC, SR, EM
|JC to approach the DH 2014 committee and find out how they would prefer us to do it, and whether it’s a good idea; and tell the Board that HC, SR and EM are prepared to be involved in organizing this along with one or more Board members.
|Done
|-
|[https://sourceforge.net/p/tei/feature-requests/264/ FR 264] altIdentifier in msPart (AMBER pending-accepted). Action: JC to change to Green and assign to himsel...
|JC
|JC to change to Green and assign to himself, then nudge Torsten for an example of an altIdentifier within an msPart.
|Done (awaiting example)
|-
|[https://sourceforge.net/p/tei/bugs/276/ BUG 276] internationalisation links (AMBER open). Language links at bottom of a page should take you to same ...
|JC, SB
|JC to make Green and allocate to SB.
|Ticket Implemented by SR; Closed.
|-
|[https://sourceforge.net/p/tei/bugs/515/ BUG 515] Bad example of feature/@fVal (AMBER open). [Change this to RED as it’s not clear what needs changin...
|JC
|JC to check that’s been changed to RED [DONE].
|Done
|-
|[https://sourceforge.net/p/tei/bugs/582/ BUG 582] Need for consistency in terminology relating to TEI conformance (AMBER open). Working group: Agreed ...
|JC
|JC will create a ticket to reconsider the discussion of “conformable” and “conformant” in the Guidelines.
|
|-
|[https://sourceforge.net/p/tei/bugs/601/ BUG 601] att.patternReplacement/@matchPattern should be XPath regex, not XML Schema (AMBER open). Action: JC ...
|JC
|JC to close as a dupe of FR 432.
|Done
|-
|[https://sourceforge.net/p/tei/feature-requests/460/ FR 460] Use of geogFeat in transcription? (GREEN open). Ok. Action: JC to do it before next teleconference....
|JC
|JC to do it before next teleconference.
|not done
|-
|[https://sourceforge.net/p/tei/feature-requests/474/ FR 474] add an exemplum for @ref (GREEN open). Action: JC to poke JC; deadline by next teleconference....
|JC
|JC to poke JC; deadline by next teleconference.
|Done
|-
|[https://sourceforge.net/p/tei/feature-requests/475/ FR 475] Stop using attributes to store space-delimited values (GREEN open). Nothing wrong with space-delimit...
|JC
|JC to Close as Closed-rejected.
|Done
|-
|[https://sourceforge.net/p/tei/feature-requests/401/ FR 401] extend and clarify use of particDesc and settingDesc (GREEN open). JC admits sloth and will implemen...
|JC
|JC to implement before next teleconference; Council decides it might be better to add these (model.
|Done
|-
|[http://sourceforge.net/p/tei/feature-requests/378/ FR 378] ; c.f. A Generic Formalism for Encoding Standoff annotations in TEI). Action: JC to ask Peter Stadle...
|JC, HC, SB
|JC to ask Peter Stadler if he’d like to attend as Council rep; otherwise any interested members of Council (HC,SB) are encouraged to attend virtually.
|Done
|-
|[https://sourceforge.net/p/tei/bugs/229/ BUG 229] Check desc of all xs:anyURI atts for in-doc restrictions (GREEN pending). We got rid of data.code al...
|JC
|JC to check prose discussion all xsd:anyURI attributes by next teleconference.
|pending
|-
|[https://sourceforge.net/p/tei/bugs/336/ BUG 336] AdBlock blocks 'msad' ID (GREEN pending-later). Per last comment, time has passed and nothing else h...
|JC
|JC to close ticket.
|Done
|-
|[https://sourceforge.net/p/tei/bugs/587/ BUG 587] Guidelines version info on pages should link better (GREEN open). Action: JC to carry out his last c...
|JC
|JC to carry out his last comment on the ticket.
|not done
|-
|[https://sourceforge.net/p/tei/bugs/519/ BUG 519] Make lb, pb, cb, gb consistent (GREEN open-accepted). Council decided to close. Action: JC to close ...
|JC
|JC to close [DONE].
|Done
|-
|[https://sourceforge.net/p/tei/bugs/525/ BUG 525] citedRange and biblScope should share att class (GREEN open). SB admitted to sloth. Action: SB to co...
|MH, JC, KH
|MH to check Allura settings to make sure that the owners of both bugs and feature requests receive email notifications. [JC and KH looked into this during a break and might have fixed it through another mechanism. MH to check with JC].
|unsure
|-
|[https://sourceforge.net/p/tei/bugs/418/ BUG 418] Names and Dates chapter does not mention calendar (GREEN open). Action: JC will add the prose before...
|JC
|JC will add the prose before the next teleconference.
|not done
|}

===Actions for Kevin Hawkins===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|[https://sourceforge.net/p/tei/feature-requests/457/ FR 457] : KH: In the ticket I want to clarify what you use tagUsage for and what to put in a project-specifi...
|KH, LB, JC
|KH, LB, and JC will review and make a recommendation to Council before the next face-to-face.
|Discussion happening on ticket.
|-
|[https://sourceforge.net/p/tei/feature-requests/384/ FR 384] that once 384 is implemented, we’ll add a note on att.typed reminding people that this is meant for ...
|HC, KH
|HC will implement [DONE]. KH will add a comment to FR 384 [DONE].
|done during Council meeting
|-
|[https://sourceforge.net/p/tei/feature-requests/468/ FR 468] : HC: precision expresses false precision that’s not real probability. It’s something more like cert...
|KH
|KH to add to the deprecation document the requirement to announce to the community that we plan to deprecate something and to get in touch if you object.
|done 2013-12-26
|-
|[https://sourceforge.net/p/tei/feature-requests/383/ FR 383] where to put idno within biblStruct? (AMBER open) This is one of three tickets where KH could not fi...
|KH, SB
|KH will create a new ticket pointing to this and the other two tickets with deprecation problems (as listed on the wiki) saying we need a way to deprecate members of content model and reassign to SB to solve the three tickets using a Schematron warning, and to add @validUntil on constraintSpec.
|done 2013-12-08 (new ticket is at https://sourceforge.net/p/tei/feature-requests/486/)
|-
|[https://sourceforge.net/p/tei/feature-requests/482/ FR 482] The term strikes back - terminology chapter (AMBER open). The ISO is working on a standard for termi...
|LB, KH, SB
|LB, KH and SB to articulate a more generic policy for TEI on the integration of external standards and will generate a one-page proposal for this policy. This should be provided to Council ahead of the next teleconference. In addition, LB, KH, and SB will check with Laurent that he wants TBX incorporated into the Guidelines as is or kept in sync in the future and what he thinks about melding into the rest of the TEI Guidelines (in language, approach, element naming conventions) or keeping it self-contained.
|Kevin drafted a [http://www.tei-c.org/Activities/Council/Working/tcw28.xml generic policy] and circulated to Lou and Syd on 2013-12-26. Discussion of whether to incorporate TBX into the Guidelines is [http://sourceforge.net/p/tei/feature-requests/482/#28f3 happening on ticket].
|-
|[https://sourceforge.net/p/tei/feature-requests/294/ FR 294] altIdentifier is deprecated within msPart (AMBER open). Action: KH to change to Green and add to the...
|KH
|KH to change to Green and add to the ticket about deprecation using Schematron along with 383, if not already done.
|done 2013-12-08
|-
|[https://sourceforge.net/p/tei/bugs/528/ BUG 528] consistency in "the Guidelines" vs. "these Guidelines" (AMBER open). This should be green. Action: K...
|KH
|KH to do this.
|
|-
|[https://sourceforge.net/p/tei/bugs/548/ BUG 548] use of modal verbs in Guidelines (AMBER pending-later). Already assigned to KH. RW agreed to help. I...
|KH, RW, LB
|KH and RW to create a new, detailed ticket with all questionable cases. In the meantime, LB will fix the edits that KH made at r12525.
|LB commented out otiose paragraph.
|-
|[https://sourceforge.net/p/tei/bugs/216/ BUG 216] half title pages in TEI Tite (AMBER open-postponed). KH has to finish comparing TEI-Tite with the Ap...
|KH
|KH to resolve Tite problems and report regularly to Council on progress.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/280/ FR 280] clarification of colloc (GREEN pending-accepted). #1 is already done. #2: Breakout group agreed that...
|KH
|KH to remove @type from both examples, etc.
|done 2013-12-26
|-
|[https://sourceforge.net/p/tei/feature-requests/482/ FR 482] Earlier we decided:Action: LB, KH and SB to articulate a more generic policy for TEI on the integrat...
|LB, KH, SB
|LB, KH and SB to articulate a more generic policy for TEI on the integration of external standards and will generate a one-page proposal for this policy. This should be provided to Council ahead of the next teleconference. In addition, LB, KH, and SB will check with Laurent that he wants TBX incorporated into the Guidelines as is or kept in sync in the future and what he thinks about melding into the rest of the TEI Guidelines (in language, approach, element naming conventions) or keeping it self-contained.
|Kevin drafted a [http://www.tei-c.org/Activities/Council/Working/tcw28.xml generic policy] and circulated to Lou and Syd on 2013-12-26. Discussion of whether to incorporate TBX into the Guidelines is [http://sourceforge.net/p/tei/feature-requests/482/#28f3 happening on ticket].
|-
|[https://sourceforge.net/p/tei/bugs/525/ BUG 525] citedRange and biblScope should share att class (GREEN open). SB admitted to sloth. Action: SB to co...
|MH, JC, KH
|MH to check Allura settings to make sure that the owners of both bugs and feature requests receive email notifications. [JC and KH looked into this during a break and might have fixed it through another mechanism. MH to check with JC].
|n/a
|}

===Actions for Martin Holmes===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|[https://sourceforge.net/p/tei/feature-requests/453/ FR 453] a place for metadata that you can't fit into existing header elements AMBER open Discussion talks mo...
|MH, PS, LB
|MH will offer DC examples and PS will offer MARC examples. LB will pull them together into some text to be inserted into the Guidelines. Given this, Council will reconsider the feature request and whether to create the wrapper element.
|Examples provided 2013-11-20
|-
|[https://sourceforge.net/p/tei/feature-requests/471/ FR 471] extend the possible usages of argument (AMBER open). (If the intended use case is encoder-supplied a...
|LB, MH
|
|Done. Fourth example added in rev 12666 2013-11-27.
|-
|[https://sourceforge.net/p/tei/feature-requests/472/ FR 472] docDate in dateline ? EM: dateline does not allow docDate, but byline allows docAuthor. This is inco...
|MH
|MH to add docDate to dateline, and clarify with usage notes.
|Done 2013-11
|-
|[https://sourceforge.net/p/tei/feature-requests/443/ FR 443] @resp should be a member of att.global AMBER open. JC and SR: Global attributes should really not be...
|MH, LB
|MH and LB to agree on clarification to Guidelines to say that @resp means different things: responsibility for markup and content except when the element in question is a transcriptional element, in which case the content of the element is marked as coming from the source.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/303/ FR 303] check the apache logs for frequent 404s (AMBER open). Action: JC to ask DS to make the TEI-C webserv...
|JC, MH
|JC to ask DS to make the TEI-C webserver logs available somewhere we can see them; then action on MH to write script to generate lists of bad links of various types. JC also to check google analytics/Webmaster tools. Deadline to report back by next conference call.
|I've checked through the logs, which the webmaster provided for me. There seem to be no instances of systematic errors. There seems to be little to gain from this, assuming the sysadmins are already routine monitoring.
|-
|[https://sourceforge.net/p/tei/feature-requests/470/ FR 470] att.measurement and att.dimensions overlap (AMBER open). We are not really sure why all of these att...
|MH
|MH to move @commodity into its own class, and move measure and measureGrp to att.dimensions. Ticket to GREEN, assign to MH. [Subsequent study suggests to MH that this may be more complicated than it seems, and may have to wait on our having the ability to override valLists in attributes from attribute classes at the element level.]
|Set back to Amber pending further discussion. See ticket for details.
|-
|[http://wiki.tei-c.org/index.php/Council_agenda_2013-11#More_Details_on_Agenda_topics bottom of wiki agenda page] ) SR: Why are we proposing using alpha and beta? MH: Because we were proposing asking the community ...
|MH, SR
|Assign MH to update the release documentation re alpha and beta, and investigate how we might add the SVN last changed date and the rev number to the bottom of pages.
|Latter bit done by SR 2013-11-14. Documentation in TCW22 updated by MH 2013-11-14.
|-
|[https://sourceforge.net/p/tei/feature-requests/405/ FR 405] Wrong schema generated (AMBER pending-accepted). This is due to a bug in the current version in Roma...
|MH
|MH to see if it has been fixed, and if so, close the ticket.
|Done 2013-11
|-
|[https://sourceforge.net/p/tei/feature-requests/342/ FR 342] [http://wiki.tei-c.org/index.php/Text_Directionality_Draft first draft of new Guidelines sections] and questions [MH] MH summarized the genesis of this text from Providence.
|MH, LB
|Entire Council to (re)read MH’s draft before next face-to-face meeting. Once we’ve done that and agreed, someone will rewrite chapter 5 (WD) to include MH’s draft and the current section 10.6.6. LB volunteered.
|Council and the WG members have been asked to read and comment on the draft (2013-11-28).
|-
|[https://sourceforge.net/p/tei/bugs/578/ BUG 578] partial and recursive segmentation of s-units (AMBER open). [The Guidelines text is clear enough. Th...
|MH
|MH will revise content model to match the prose.
|Done 2013-11-27, although I really don't like the results of this.
|-
|[https://sourceforge.net/p/tei/feature-requests/298/ BUG 298] att.editLike should not bring att.dimensions & att.ranging (AMBER open-accepted). [MH to ask Gabriel...
|MH
|MH to ask Gabby to implement.
|GB has asked to pass the ticket to MH (2013-11-28). MH to create a full proposal and implement if approved.
|-
|[https://sourceforge.net/p/tei/feature-requests/212/ FR 212] Generic dating class (AMBER pending-accepted). Gabby claimed in 2011 that it’s done except needs som...
|HC, MH
|HC to investigate whether it’s actually been done. MH offered examples if needed.
|Hugh has opened a new bug [https://sourceforge.net/p/tei/bugs/635/ #635] to address this.
|-
|[https://sourceforge.net/p/tei/bugs/568/ BUG 568] "How to edit the Guidelines" and chapter organization (AMBER open). SR: What MH found looks distinct...
|MH
|MH to replace references to entity references with explanation of XIncludes in “How to edit the Guidelines”.
|Done 2013-11
|-
|[https://sourceforge.net/p/tei/bugs/506/ BUG 506] Meaning of @corresp rather in dispute (AMBER open). Working group triage: needs to be discussed: Is ...
|MH
|MH to create an example and run it by tei-council before adding to the Guidelines.
|Done 2013-12-23
|-
|[https://sourceforge.net/p/tei/bugs/582/ BUG 582] Need for consistency in terminology relating to TEI conformance (AMBER open). Working group: Agreed ...
|MH
|MH to deal with the ticket narrowly, using a hyphen and lowercase but leaving both “conformant” and “conformable”.
|Done 2013-11-20
|-
|[https://sourceforge.net/p/tei/bugs/460/ BUG 460] list/@type="unordered" is not recommended, but used often (AMBER open). Working group: This bug has...
|MH
|MH to follow the last comment on ticket to figure out our current situation.
|Research done, and a proposal being developed [http://wiki.tei-c.org/index.php/List_types_and_rendering on the wiki].
|-
|[https://sourceforge.net/p/tei/bugs/581/ BUG 581] `attRef` needs better documentation (AMBER open). Action: SR to implement either removal of attRef, ...
|SR, MH
|SR to implement either removal of attRef, MH to adjust documentation.
|SR recommends holding off on documentation because he may be able to eliminate attRef in favour of classRef.
|-
|[https://sourceforge.net/p/tei/feature-requests/432/ FR 432] Change regex flavor on @matchPattern (GREEN open). Agreed, XPath. Action: MH Write to TEI-L list, if...
|MH
|MH Write to TEI-L list, if no negative feedback, change.
|Done 2013-11-21 rev 12660
|-
|[https://sourceforge.net/p/tei/bugs/312/ BUG 312] i18n revision due (GREEN open). Action: MH, when he completes action on related ticket (perhaps afte...
|MH
|MH, when he completes action on related ticket (perhaps after moving notes from minutes into tickets), to update this ticket.
|Some contacts made with potential translators 2013-12; suggestion for a pilot project with Italian and Chinese posted to Council list.
|-
|[https://sourceforge.net/p/tei/bugs/442/ BUG 442] update ODD documentation on www.tei-c.org and in Guidelines (GREEN open). Action: MH to finish it....
|MH
|MH to finish it.
|
|-
|[https://sourceforge.net/p/tei/bugs/441/ BUG 441] fDecl doesn't allow att.datcat yet (GREEN open-accepted). Action: MH to prod Piotr....
|MH
|MH to prod Piotr.
|Piotr prodded 2013-11-21, and twice more after that.
|-
|[https://sourceforge.net/p/tei/bugs/525/ BUG 525] citedRange and biblScope should share att class (GREEN open). SB admitted to sloth. Action: SB to co...
|MH, JC, KH
|MH to check Allura settings to make sure that the owners of both bugs and feature requests receive email notifications. [JC and KH looked into this during a break and might have fixed it through another mechanism. MH to check with JC].
|According to investigation, we've done what we can with Allura settings here.
|}

===Actions for Elli Mylonas===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|Ideas on how to run an experimental TEI Hackathon [SR]

|JC, HC, SR, EM
|JC to approach the DH 2014 committee and find out how they would prefer us to do it, and whether it’s a good idea; and tell the Board that HC, SR and EM are prepared to be involved in organizing this along with one or more Board members.
|JC did, hand off to EM Jan 9 '14 DONE
|-
|Ideas on how to run an experimental TEI Hackathon [SR]

|EM
|EM to make sure this happens.
|Jan 28 '14 Discussions begun, proposal draft begun. Feb 21 proposal submitted to DH2014 DONE
|-
|[https://sourceforge.net/p/tei/feature-requests/300/ FR 300] Move witStart et al. to model.milestoneLike (AMBER pending). Action: EM to change to red and assigne...
|EM
|EM to change to red and assigned to EM to chase up or otherwise close ticket.
|
|-
|[https://sourceforge.net/p/tei/bugs/594/ BUG 594] TEI-C website menu points to wrong index page for Guidelines (AMBER open). Fixed, will appear in nex...
|EM
|EM to create a ticket on the Chrome problem.
|Dec 10, 2013 done
|-
|[https://sourceforge.net/p/tei/bugs/589/ BUG 589] add respons and space to att.responsibility (AMBER open). Working group triage: Is it ok to add have...
|EM
|EM will get rid of locally assigned @resp by adding to att.responsibility (thereby getting @cert as well). Will change to GREEN.
|Dec 10, 2013 Done
|-
|[https://sourceforge.net/p/tei/bugs/563/ BUG 563] inconsistent encoding of citations to sources of examples (AMBER open). Working group recommends ass...
|BB, EM, PS
|BB, EM, and PS to work on the ticket by mid-February 2014.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/389/ FR 389] clarify definition of @from on locus and biblScope (GREEN open). EM admits to sloth and will do so. ...
|EM
|EM to do before next teleconference.
|
|-
|[http://wiki.tei-c.org/index.php/TEI_Cheatsheets Cheatsheets: Short best/recommended practice documents] EM: Not cheatsheets - negative implication. RW: Quick Start. HC: Quick Reference; SB: “Guidelettes” ...
|EM
|EM to ask MB to clarify what she wants from Council with regard to helping cheatsheets.
|
|}

===Actions for Sebastian Rahtz===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|[http://tei.oucs.ox.ac.uk/EEBO/ http://tei.oucs.ox.ac.uk/EEBO/] for summary of problem, and links to tickets) SR: EEBO-TCP is a gigantic resource that claims to be ...
|SR
|SR will implement the schema change of adding @place to stage and will document and provide an example.
|adding @place. example to do
|-
|[https://sourceforge.net/p/tei/feature-requests/479/ FR 479] Adding the @place attribute to head and seg AMBER open JC noted that head is not meta-textual or in ...
|SR
|SR to take the ticket, and get more examples from the submitter
|DONE
|-
|[https://sourceforge.net/p/tei/feature-requests/445/ FR 445] Conversion of ODD to HTML: Examples should be aware of element renaming closed-fixed, implemented by...
|SR
|SR to add gi and att renaming to complete the ticket.
| COMPLETED FOR gi. Not possible for att.
|-
|[https://sourceforge.net/p/tei/feature-requests/442/ FR 442] Allow foreign to contain q (AMBER open). The group felt this should be rejected. Action:SR to close ...
|SR
|SR to close ticket because it’s rejected
|DONE
|-
|[https://sourceforge.net/p/tei/feature-requests/433/ FR 433] loosen content model of salute (AMBER open). SR: Underlying this was a desire for symmetry between s...
|SR
|SR will carry this out
|DONE
|-
|[https://sourceforge.net/p/tei/feature-requests/477/ FR 477] lines of poetry inside trailer (AMBER open). The request is for symmetry between head and trailer. T...
|SR
|SR to find a good way to achieve this, since what was done before with head was rather strange.
|DONE. Have copied what was done with head
|-
|[https://sourceforge.net/p/tei/feature-requests/383/ FR 383] where to put idno within biblStruct? (AMBER open) This is one of three tickets where KH could not fi...
|SR
|SR to check how @validUntil makes the build fail when out of date, and if necessary update this mechanism so it can handle @validUntil on constraintSpec. Ticket 383 will wait on all this, along with the two other tickets.
|DONE. It applies to tei:*[@validUntil], so should just work.] .
|-
|[http://wiki.tei-c.org/index.php/Council_agenda_2013-11#More_Details_on_Agenda_topics bottom of wiki agenda page] ) SR: Why are we proposing using alpha and beta? MH: Because we were proposing asking the community ...
|MH, SR
|Assign MH to update the release documentation re alpha and beta, and investigate how we might add the SVN last changed date and the rev number to the bottom of pages.
|Latter bit done by SR 2013-11-14. Documentation in TCW22 updated by MH 2013-11-14.]
|-
|Ideas on how to run an experimental TEI Hackathon [SR]
|JC, HC, SR, EM
|JC to approach the DH 2014 committee and find out how they would prefer us to do it, and whether it’s a good idea; and tell the Board that HC, SR and EM are prepared to be involved in organizing this along with one or more Board members.
|EM submitted bid from TEI on time, after consultation with SR, HC and Arianna
|-
|[https://sourceforge.net/p/tei/feature-requests/345/ FR 345] members of model.respLike should be members of att.declarable (AMBER open-later). Breakout group ins...
|SR
|SR to make the ticket Green and go ahead and implement it, including some documentation/examples.
|DONE
|-
|[https://sourceforge.net/p/tei/bugs/302/ BUG 302] version ignores @source (AMBER open). This is a Roma issue. Recommend marking as closed won’t fix be...
|SR
|SR to try reproducing this and set as closed-won’t fix.
|DONE
|-
|[https://sourceforge.net/p/tei/bugs/583/ BUG 583] Adding new attribute fails in Roma schema generation (AMBER open). Same as 302. Action: SR wil set a...
|SR
|SR wil set as closed-won’t fix and check that it has the Roma tag.
|DONE
|-
|[https://sourceforge.net/p/tei/bugs/434/ BUG 434] issues with ePub conversion (2/3) (AMBER open). Any issue not dealing with ODD processing should be ...
|SR
|SR will ask poster kindly to post there (explaining why) and close this issue.
|DONE
|-
|[https://sourceforge.net/p/tei/bugs/581/ BUG 581] `attRef` needs better documentation (AMBER open). Action: SR to implement either removal of attRef, ...
|SR, MH
|SR to implement either removal of attRef, MH to adjust documentation.
|FIxed attRef. thinking about classRef. some changes made to implementation of that. attRef still needed.
|-
|[https://sourceforge.net/p/tei/feature-requests/467/ FR 467] Make @name optional on tei:relation (GREEN open). Action: SR has already done this....
|SR
|SR to action
|DOne
|-
|[https://sourceforge.net/p/tei/feature-requests/478/ FR 478] loosening content and model of `signed` (GREEN open). Agree that is is green. Though would model.div...
|SR
|SR to implement signed at top as well as bottom
|DONE
|}

===Actions for Paul Schaffner===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|[https://sourceforge.net/p/tei/feature-requests/453/ FR 453] a place for metadata that you can't fit into existing header elements AMBER open Discussion talks mo...
|MH, PS, LB
|MH will offer DC examples and PS will offer MARC examples. LB will pull them together into some text to be inserted into the Guidelines. Given this, Council will reconsider the feature request and whether to create the wrapper element.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/360/ FR 360] New attribute @keepHyphen. Ticket open, ticket GREEN, it’s rejected throughout the comments....
|PS
|PS to provide an example of the mechanism recommended to handle the use-case.
|
|-
|[https://sourceforge.net/p/tei/bugs/563/ BUG 563] inconsistent encoding of citations to sources of examples (AMBER open). Working group recommends ass...
|BB, EM, PS
|BB, EM, and PS to work on the ticket by mid-February 2014.
|
|-
|[https://sourceforge.net/p/tei/bugs/558/ BUG 558] name/orgName (AMBER open). Action: RW to ask PS where he is on this; change ticket status to GREEN....
|RW, PS
|RW to ask PS where he is on this; change ticket status to GREEN.
|
|}

===Actions for Torsten Schassan===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|

|TS
|TS to come up with a more detailed problem description and what the WG should attempt to solve by 2014-01-01.
|
|}

===Actions for Rebecca Welzenbach===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|[https://sourceforge.net/p/tei/feature-requests/384/ FR 384] : In April RW made a spreadsheet showing which elements she recommends moving into att.typed. And in...
|SB, RW
|SB and RW will review the list again.
|
|-
|Attributes without examples

|BB, RW
|BB and RW to turn into bug reports those attributes that are without examples that are high priority or need new/updated definitions.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/377/ FR 377] retaining punctuation marks in the text of a TEI document (AMBER open-accepted). RW says she has add...
|RW
|RW to finish the work and ask for help if necessary.
|
|-
|[https://sourceforge.net/p/tei/bugs/548/ BUG 548] use of modal verbs in Guidelines (AMBER pending-later). Already assigned to KH. RW agreed to help. I...
|KH, RW, LB
|KH and RW to create a new, detailed ticket with all questionable cases. In the meantime, LB will fix the edits that KH made at r12525.
|
|-
|[https://sourceforge.net/p/tei/bugs/558/ BUG 558] name/orgName (AMBER open). Action: RW to ask PS where he is on this; change ticket status to GREEN....
|RW, PS
|RW to ask PS where he is on this; change ticket status to GREEN.
|
|-
|[https://sourceforge.net/p/tei/bugs/401/ BUG 401] Most attributes lack good examples (GREEN open-accepted). This was previously discussed. Action: RW ...
|RW
|RW to follow up.
|
|}

[[Category:Council]]

Oxford2013-Actions2

2014-03-07T14:12:52Z

Rahtz: /* Actions for Sebastian Rahtz */

==Council Actions from November 2013 Oxford Meeting==

A list of actions, those responsible, and what has been done about them from [http://www.tei-c.org/Activities/Council/Meetings/tcm56.xml Oxford 2013 face to face meeting] of TEI Technical Council

===Actions for Brett Barney===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|Attributes without examples

|BB, RW
|BB and RW to turn into bug reports those attributes that are without examples that are high priority or need new/updated definitions.
|
|-
|[https://sourceforge.net/p/tei/bugs/563/ BUG 563] inconsistent encoding of citations to sources of examples (AMBER open). Working group recommends ass...
|BB, EM, PS
|BB, EM, and PS to work on the ticket by mid-February 2014.
|
|-
|[https://sourceforge.net/p/tei/bugs/610/ BUG 610] "lem" used in a confusing way in CriticalApparatus.xml (AMBER open). Action: BB to remove the last c...
|BB
|BB to remove the last clause of the sentence in question, beginning ", or to make clear".
|Done 2013-11-13
|-
|[https://sourceforge.net/p/tei/bugs/387/ BUG 387] clarifying heading or title of a graphic (GREEN open). LB recently posted a comment approving of the...
|BB
|BB will implement the ticket.
|Done 2013-11-13
|}

===Actions for Lou Burnard===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|[https://sourceforge.net/p/tei/feature-requests/457/ FR 457] : KH: In the ticket I want to clarify what you use tagUsage for and what to put in a project-specifi...
|KH, LB, JC
|KH, LB, and JC will review and make a recommendation to Council before the next face-to-face.
|KH emailed the others on 2013-12-26; LB updated ticket and emailed the others 2014-01-05
|-
|[https://sourceforge.net/p/tei/feature-requests/453/ FR 453] a place for metadata that you can't fit into existing header elements AMBER open Discussion talks mo...
|MH, PS, LB
|MH will offer DC examples and PS will offer MARC examples. LB will pull them together into some text to be inserted into the Guidelines. Given this, Council will reconsider the feature request and whether to create the wrapper element.
|Added comment on ticket suggesting that the proposal seems doomed to be rejected; action to explain how to handle this situation in the Guidelines remains open.
|-
|[https://sourceforge.net/p/tei/feature-requests/471/ FR 471] extend the possible usages of argument (AMBER open). (If the intended use case is encoder-supplied a...
|LB, MH
|New element <abstract> added; examples added .
|Done 2013-11-12
|-
|Pure ODD

|LB
|LB to add the new elements and the documentation ahead of the next release; documentation need only be at the element level, along with some brief introduction in the Guidelines, to be expanded to a full section later.
|First pass completed 2013-12-01
|-
|[https://sourceforge.net/p/tei/feature-requests/443/ FR 443] @resp should be a member of att.global AMBER open. JC and SR: Global attributes should really not be...
|MH, LB
|MH and LB to agree on clarification to Guidelines to say that @resp means different things: responsibility for markup and content except when the element in question is a transcriptional element, in which case the content of the element is marked as coming from the source.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/366/ FR 366] rationalize content models of org and place (etc) (AMBER open). Group thinks a small group of people...
|JC, LB, SB
|JC to make ticket red, should stay with JC, and he should initiate the process, working with LB and SB.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/458/ FR 458] Make listBibl and model.biblLike member of model.personPart (AMBER open). Lou has already done items...
|LB
|close the ticket.
|Done
|-
|i18n: take forward updating translations

|LB
|LB to testdrive the spreadsheet.
|Done
|-
|[https://sourceforge.net/p/tei/feature-requests/482/ FR 482] The term strikes back - terminology chapter (AMBER open). The ISO is working on a standard for termi...
|LB, KH, SB
|LB, KH and SB to articulate a more generic policy for TEI on the integration of external standards and will generate a one-page proposal for this policy. This should be provided to Council ahead of the next teleconference. In addition, LB, KH, and SB will check with Laurent that he wants TBX incorporated into the Guidelines as is or kept in sync in the future and what he thinks about melding into the rest of the TEI Guidelines (in language, approach, element naming conventions) or keeping it self-contained.
|Kevin drafted a [http://www.tei-c.org/Activities/Council/Working/tcw28.xml generic policy] and circulated to Lou and Syd on 2013-12-26. Discussion of whether to incorporate TBX into the Guidelines is [http://sourceforge.net/p/tei/feature-requests/482/#28f3 happening on ticket].
|-
|[https://sourceforge.net/p/tei/feature-requests/480/ FR 480] Adding the @hand attribute to all (or most) text-containing elements (AMBER open). Breakout group wa...
|LB
|LB to respond to the ticket FR 480.
|
|-
|[http://wiki.tei-c.org/index.php/Text_Directionality_Draft first draft of new Guidelines sections] and questions [MH] MH summarized the genesis of this text from Providence. He noted that not only th...
|MH, LB
|Entire Council to (re)read MH’s draft before next face-to-face meeting. Once we’ve done that and agreed, someone will rewrite chapter 5 (WD) to include MH’s draft and the current section 10.6.6. LB volunteered.
|
|-
|[https://sourceforge.net/p/tei/bugs/548/ BUG 548] use of modal verbs in Guidelines (AMBER pending-later). Already assigned to KH. RW agreed to help. I...
|KH, RW, LB
|KH and RW to create a new, detailed ticket with all questionable cases. In the meantime, LB will fix the edits that KH made at r12525.
|Commented out otiose paragraph.
|-
|[https://sourceforge.net/p/tei/bugs/468/ BUG 468] Order of elements in publicationStmt (AMBER open-accepted). Group discussion: SB: Despite Lou’s comm...
|SB, LB
|SB will do the content model and LB will do the prose. They’ll work out the specifics.
|Emailed syd 2014-01-05
|-
|[https://sourceforge.net/p/tei/feature-requests/469/ FR 469] add extent to att.dimensions (GREEN open). Agreed. Action: LB to provide an example in HD chapter (2...
|LB
|LB to provide an example in HD chapter (2.2.3) and close ticket.
|Done 2013-11-20
|-
|[https://sourceforge.net/p/tei/bugs/605/ BUG 605] clarifying add vs. supplied and del vs. surplus (AMBER open). Action: HC to emend the prose of the p...
|HC, LB
|HC to emend the prose of the paragraph beginning "The add element should not be used" to reference the surplus element also; LB points out that the specList can't be modified, because supplied/surplus aren't defined in Core.
|Done, I think.
|-
|[https://sourceforge.net/p/tei/bugs/609/ BUG 609] "lemma" used in a confusing way in CriticalApparatus.xml (AMBER open). Action: LB to remove the phra...
|LB
|LB to remove the phrase "on any one lemma" from the @varSeq description.
|Done, 2013-11-13
|-
|[https://sourceforge.net/p/tei/feature-requests/461/ FR 461] Two small improvements to `recording` (GREEN open). Action: LB to do this by next teleconference....
|LB
|LB to do this by next teleconference.
|Done 2013-11-13
|-
|[https://sourceforge.net/p/tei/feature-requests/482/ FR 482] Earlier we decided:Action: LB, KH and SB to articulate a more generic policy for TEI on the integrat...
|LB, KH, SB
|LB, KH and SB to articulate a more generic policy for TEI on the integration of external standards and will generate a one-page proposal for this policy. This should be provided to Council ahead of the next teleconference. In addition, LB, KH, and SB will check with Laurent that he wants TBX incorporated into the Guidelines as is or kept in sync in the future and what he thinks about melding into the rest of the TEI Guidelines (in language, approach, element naming conventions) or keeping it self-contained.
|Kevin drafted a [http://www.tei-c.org/Activities/Council/Working/tcw28.xml generic policy] and circulated to Lou and Syd on 2013-12-26. Discussion of whether to incorporate TBX into the Guidelines is [http://sourceforge.net/p/tei/feature-requests/482/#28f3 happening on ticket].
|-
|Correspondence SIG:

|SB, LB
|SB and LB would like to (re?-)join the task force. Council advises them to keep in mind the work by the Ontology/MS SIGs, in particular Torsten Schassan, on an ‘object’ or ‘objectDesc’ element.
|
|}

===Actions for Syd Bauman===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|[https://sourceforge.net/p/tei/feature-requests/384/ FR 384] : In April RW made a spreadsheet showing which elements she recommends moving into att.typed. And in...
|SB, RW
|SB and RW will review the list again.
|SB sent e-mail to RW 2013-12-06, no response yet (2014-01-10); pinged again 2014-02-04.
|-
|[https://sourceforge.net/p/tei/feature-requests/459/ FR 459] : This is just waiting for implementation....
|SB
|SB will implement by end of January 2014.
|SB: if I understand ticket correctly, this was done along w/ 486.
|-
|[https://sourceforge.net/p/tei/feature-requests/481/ FR 481] check that all sibling att.translatable elements have @versionDate (AMBER open). (Agreed that siblin...
|SB
|SB to check whether this is implemented, and if not, get it implemented then close the ticket.
|has now been implemented (twice, sort of); ticket closed
|-
|[https://sourceforge.net/p/tei/feature-requests/468/ FR 468] : HC: precision expresses false precision that’s not real probability. It’s something more like cert...
|SB
|
|SB: when I checked this had already been done -- HC in r12606
|-
|[https://sourceforge.net/p/tei/feature-requests/383/ FR 383] where to put idno within biblStruct? (AMBER open) This is one of three tickets where KH could not fi...
|KH, SB
|KH will create a new ticket pointing to this and the other two tickets with deprecation problems (as listed on the wiki) saying we need a way to deprecate members of content model and reassign to SB to solve the three tickets using a Schematron warning, and to add @validUntil on constraintSpec.
|This ticket reassigned to Syd, and new ticket created: https://sourceforge.net/p/tei/feature-requests/486/ .
|-
|[https://sourceforge.net/p/tei/feature-requests/366/ FR 366] rationalize content models of org and place (etc) (AMBER open). Group thinks a small group of people...
|JC, LB, SB
|JC to make ticket red, should stay with JC, and he should initiate the process, working with LB and SB.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/482/ FR 482] The term strikes back - terminology chapter (AMBER open). The ISO is working on a standard for termi...
|LB, KH, SB
|LB, KH and SB to articulate a more generic policy for TEI on the integration of external standards and will generate a one-page proposal for this policy. This should be provided to Council ahead of the next teleconference. In addition, LB, KH, and SB will check with Laurent that he wants TBX incorporated into the Guidelines as is or kept in sync in the future and what he thinks about melding into the rest of the TEI Guidelines (in language, approach, element naming conventions) or keeping it self-contained.
|Kevin drafted a [http://www.tei-c.org/Activities/Council/Working/tcw28.xml generic policy] and circulated to Lou and Syd on 2013-12-26. Discussion of whether to incorporate TBX into the Guidelines is [http://sourceforge.net/p/tei/feature-requests/482/#28f3 happening on ticket].
|-
|[https://sourceforge.net/p/tei/bugs/276/ BUG 276] internationalisation links (AMBER open). Language links at bottom of a page should take you to same ...
|JC, SB
|JC to make Green and allocate to SB.
|
|-
|[https://sourceforge.net/p/tei/bugs/619/ BUG 619] tei_allPlus.rng: conflicting ID-types for attribute "id" of element "partialdiff" from namespace "ht...
|SB
|SB to double-check whether able to reproduce and report back on ticket if able to.
|DONE. Tried both with Options > Preferences > XML > XML Parser > RELAX NG > Check ID/IDREF checked and unchecked against tei_allPlus.rng 2.5.0, and did not reproduce error.
|-
|[https://sourceforge.net/p/tei/bugs/288/ BUG 288] deprecate use of gram except as a child of gramGrp (AMBER open-accepted). [This is pending creation ...
|SB
|SB to create the new ticket and write the Schematron for this particular deprecation.
|Elsewhere we decided that KH would create the new ticket, which he's done at https://sourceforge.net/p/tei/feature-requests/486/ . But SB still needs to solve this ticket.
|-
|[https://sourceforge.net/p/tei/bugs/468/ BUG 468] Order of elements in publicationStmt (AMBER open-accepted). Group discussion: SB: Despite Lou’s comm...
|SB, LB
|SB will do the content model and LB will do the prose. They’ll work out the specifics.
|Content model checked-in w/ typo at r12736, fixed in r12748.
|-
|[https://sourceforge.net/p/tei/bugs/405/ BUG 405] XPointer schemes may not nest, but see ch. 16 (AMBER open). Action: SB to fix documentation....
|SB
|SB to fix documentation.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/482/ FR 482] Earlier we decided:Action: LB, KH and SB to articulate a more generic policy for TEI on the integrat...
|LB, KH, SB
|LB, KH and SB to articulate a more generic policy for TEI on the integration of external standards and will generate a one-page proposal for this policy. This should be provided to Council ahead of the next teleconference. In addition, LB, KH, and SB will check with Laurent that he wants TBX incorporated into the Guidelines as is or kept in sync in the future and what he thinks about melding into the rest of the TEI Guidelines (in language, approach, element naming conventions) or keeping it self-contained.
|Kevin drafted a [http://www.tei-c.org/Activities/Council/Working/tcw28.xml generic policy] and circulated to Lou and Syd on 2013-12-26. Discussion of whether to incorporate TBX into the Guidelines is [http://sourceforge.net/p/tei/feature-requests/482/#28f3 happening on ticket].
|-
|[http://sourceforge.net/p/tei/feature-requests/378/ FR 378] ; c.f. A Generic Formalism for Encoding Standoff annotations in TEI). Action: JC to ask Peter Stadle...
|JC, HC, SB
|JC to ask Peter Stadler if he’d like to attend as Council rep; otherwise any interested members of Council (HC,SB) are encouraged to attend virtually.
|
|-
|Correspondence SIG:

|SB, LB
|SB and LB would like to (re?-)join the task force. Council advises them to keep in mind the work by the Ontology/MS SIGs, in particular Torsten Schassan, on an ‘object’ or ‘objectDesc’ element.
|
|-
|[https://sourceforge.net/p/tei/bugs/525/ BUG 525] citedRange and biblScope should share att class (GREEN open). SB admitted to sloth. Action: SB to co...
|SB
|SB to complete.
|done, at r12767
|}

===Actions for Hugh Cayless===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|Report on specification and estimated cost for XPointer resolver [HC/SB]

|HC
|HC to report on XPointer resolver and whether we should progress it.
|Draft GLs revision posted on [http://hcayless.github.io/TEI-Guidelines/Guidelines-web/en/html/SA.html#SATS GitHub]
|-
|[https://sourceforge.net/p/tei/feature-requests/465/ FR 465] : Gabby and HC seem to agree on it, and the example looks sensible. LB’s comment could be raised as ...
|HC
|HC will implement before end of January 2014.
|Done.
|-
|[https://sourceforge.net/p/tei/feature-requests/384/ FR 384] that once 384 is implemented, we’ll add a note on att.typed reminding people that this is meant for ...
|HC, KH
|HC will implement [DONE]. KH will add a comment to FR 384 [DONE].
|done during Council meeting
|-
|[https://sourceforge.net/p/tei/feature-requests/462/ FR 462] idno@type='uri' for Linked Data AMBER open (We agreed. @type=”URI” alongside @type=”URL”) EM: The su...
|HC
|HC to implement this and close the ticket FR 462.
|Done.
|-
|[https://sourceforge.net/p/tei/feature-requests/468/ FR 468] : HC: precision expresses false precision that’s not real probability. It’s something more like cert...
|HC
|HC to email TEI-L.
|FR implemented at meeting and email sent. No agitated (or indeed, any) responses.
|-
|Ideas on how to run an experimental TEI Hackathon [SR]

|JC, HC, SR, EM
|JC to approach the DH 2014 committee and find out how they would prefer us to do it, and whether it’s a good idea; and tell the Board that HC, SR and EM are prepared to be involved in organizing this along with one or more Board members.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/212/ FR 212] Generic dating class (AMBER pending-accepted). Gabby claimed in 2011 that it’s done except needs som...
|HC, MH
|HC to investigate whether it’s actually been done. MH offered examples if needed.
|Gabby says the element/classSpecs were done, but corresponding prose was never added to the Guidelines. Opened a new bug [https://sourceforge.net/p/tei/bugs/635/ #635] to address that.
|-
|[https://sourceforge.net/p/tei/bugs/605/ BUG 605] clarifying add vs. supplied and del vs. surplus (AMBER open). Action: HC to emend the prose of the p...
|HC, LB
|HC to emend the prose of the paragraph beginning "The add element should not be used" to reference the surplus element also; LB points out that the specList can't be modified, because supplied/surplus aren't defined in Core.
|Done.
|-
|[http://sourceforge.net/p/tei/feature-requests/378/ FR 378] ; c.f. A Generic Formalism for Encoding Standoff annotations in TEI). Action: JC to ask Peter Stadle...
|JC, HC, SB
|JC to ask Peter Stadler if he’d like to attend as Council rep; otherwise any interested members of Council (HC,SB) are encouraged to attend virtually.
|
|}

===Actions for James Cummings===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|[https://sourceforge.net/p/tei/feature-requests/457/ FR 457] : KH: In the ticket I want to clarify what you use tagUsage for and what to put in a project-specifi...
|KH, LB, JC
|KH, LB, and JC will review and make a recommendation to Council before the next face-to-face.
|KH emailed the others on 2013-12-26.
|-
|[https://sourceforge.net/p/tei/feature-requests/476/ FR 476] use of stage inside poetry, and using placement attribute (AMBER open). (Council agreed to @place; s...
|JC
|JC to close ticket FR 476 noting it has been resolved.
|Done
|-
|[https://docs.google.com/document/d/1766WTJV2xcfANh8HRZW5m520yrC1nCzQJzUgKpwiylI/edit TEI Roma Replacement Specification] JC: The existing Roma is dated and flawed, as we all know. Many tickets have come up which we cannot...
|JC
|ALL Council to go through the proposal again and discuss it, remembering to look at the comments, and further refine it. JC to make sure it’s tidied up. Deadline: next teleconference.
|Not finished.
|-
|[https://sourceforge.net/p/tei/feature-requests/303/ FR 303] check the apache logs for frequent 404s (AMBER open). Action: JC to ask DS to make the TEI-C webserv...
|JC, MH
|JC to ask DS to make the TEI-C webserver logs available somewhere we can see them; then action on MH to write script to generate lists of bad links of various types. JC also to check google analytics/Webmaster tools. Deadline to report back by next conference call.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/305/ FR 305] Updating info on projects page (AMBER open). Project pages go out of date. There is a way to submit ...
|JC
|JC to ask DS to make that correction info available on each project page, along with its last-updated date if possible (and the latter should also show up on the bullet-point list).
|
|-
|[https://sourceforge.net/p/tei/feature-requests/466/ FR 466] Make it possible to add SIG labels to tickets (AMBER open). Action: JC as SIG Coordinator to tell th...
|JC
|JC as SIG Coordinator to tell the SIGs that if they wish, we can make their SIG convener a developer on SF and make it possible to assign SIG labels to tickets. Deadline: next teleconference.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/366/ FR 366] rationalize content models of org and place (etc) (AMBER open). Group thinks a small group of people...
|JC, LB, SB
|JC to make ticket red, should stay with JC, and he should initiate the process, working with LB and SB.
|
|-
|Ideas on how to run an experimental TEI Hackathon [SR]

|JC, HC, SR, EM
|JC to approach the DH 2014 committee and find out how they would prefer us to do it, and whether it’s a good idea; and tell the Board that HC, SR and EM are prepared to be involved in organizing this along with one or more Board members.
|Done
|-
|[https://sourceforge.net/p/tei/feature-requests/264/ FR 264] altIdentifier in msPart (AMBER pending-accepted). Action: JC to change to Green and assign to himsel...
|JC
|JC to change to Green and assign to himself, then nudge Torsten for an example of an altIdentifier within an msPart.
|Done (awaiting example)
|-
|[https://sourceforge.net/p/tei/bugs/276/ BUG 276] internationalisation links (AMBER open). Language links at bottom of a page should take you to same ...
|JC, SB
|JC to make Green and allocate to SB.
|Ticket Implemented by SR; Closed.
|-
|[https://sourceforge.net/p/tei/bugs/515/ BUG 515] Bad example of feature/@fVal (AMBER open). [Change this to RED as it’s not clear what needs changin...
|JC
|JC to check that’s been changed to RED [DONE].
|Done
|-
|[https://sourceforge.net/p/tei/bugs/582/ BUG 582] Need for consistency in terminology relating to TEI conformance (AMBER open). Working group: Agreed ...
|JC
|JC will create a ticket to reconsider the discussion of “conformable” and “conformant” in the Guidelines.
|
|-
|[https://sourceforge.net/p/tei/bugs/601/ BUG 601] att.patternReplacement/@matchPattern should be XPath regex, not XML Schema (AMBER open). Action: JC ...
|JC
|JC to close as a dupe of FR 432.
|Done
|-
|[https://sourceforge.net/p/tei/feature-requests/460/ FR 460] Use of geogFeat in transcription? (GREEN open). Ok. Action: JC to do it before next teleconference....
|JC
|JC to do it before next teleconference.
|not done
|-
|[https://sourceforge.net/p/tei/feature-requests/474/ FR 474] add an exemplum for @ref (GREEN open). Action: JC to poke JC; deadline by next teleconference....
|JC
|JC to poke JC; deadline by next teleconference.
|Done
|-
|[https://sourceforge.net/p/tei/feature-requests/475/ FR 475] Stop using attributes to store space-delimited values (GREEN open). Nothing wrong with space-delimit...
|JC
|JC to Close as Closed-rejected.
|Done
|-
|[https://sourceforge.net/p/tei/feature-requests/401/ FR 401] extend and clarify use of particDesc and settingDesc (GREEN open). JC admits sloth and will implemen...
|JC
|JC to implement before next teleconference; Council decides it might be better to add these (model.
|Done
|-
|[http://sourceforge.net/p/tei/feature-requests/378/ FR 378] ; c.f. A Generic Formalism for Encoding Standoff annotations in TEI). Action: JC to ask Peter Stadle...
|JC, HC, SB
|JC to ask Peter Stadler if he’d like to attend as Council rep; otherwise any interested members of Council (HC,SB) are encouraged to attend virtually.
|Done
|-
|[https://sourceforge.net/p/tei/bugs/229/ BUG 229] Check desc of all xs:anyURI atts for in-doc restrictions (GREEN pending). We got rid of data.code al...
|JC
|JC to check prose discussion all xsd:anyURI attributes by next teleconference.
|pending
|-
|[https://sourceforge.net/p/tei/bugs/336/ BUG 336] AdBlock blocks 'msad' ID (GREEN pending-later). Per last comment, time has passed and nothing else h...
|JC
|JC to close ticket.
|Done
|-
|[https://sourceforge.net/p/tei/bugs/587/ BUG 587] Guidelines version info on pages should link better (GREEN open). Action: JC to carry out his last c...
|JC
|JC to carry out his last comment on the ticket.
|not done
|-
|[https://sourceforge.net/p/tei/bugs/519/ BUG 519] Make lb, pb, cb, gb consistent (GREEN open-accepted). Council decided to close. Action: JC to close ...
|JC
|JC to close [DONE].
|Done
|-
|[https://sourceforge.net/p/tei/bugs/525/ BUG 525] citedRange and biblScope should share att class (GREEN open). SB admitted to sloth. Action: SB to co...
|MH, JC, KH
|MH to check Allura settings to make sure that the owners of both bugs and feature requests receive email notifications. [JC and KH looked into this during a break and might have fixed it through another mechanism. MH to check with JC].
|unsure
|-
|[https://sourceforge.net/p/tei/bugs/418/ BUG 418] Names and Dates chapter does not mention calendar (GREEN open). Action: JC will add the prose before...
|JC
|JC will add the prose before the next teleconference.
|not done
|}

===Actions for Kevin Hawkins===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|[https://sourceforge.net/p/tei/feature-requests/457/ FR 457] : KH: In the ticket I want to clarify what you use tagUsage for and what to put in a project-specifi...
|KH, LB, JC
|KH, LB, and JC will review and make a recommendation to Council before the next face-to-face.
|Discussion happening on ticket.
|-
|[https://sourceforge.net/p/tei/feature-requests/384/ FR 384] that once 384 is implemented, we’ll add a note on att.typed reminding people that this is meant for ...
|HC, KH
|HC will implement [DONE]. KH will add a comment to FR 384 [DONE].
|done during Council meeting
|-
|[https://sourceforge.net/p/tei/feature-requests/468/ FR 468] : HC: precision expresses false precision that’s not real probability. It’s something more like cert...
|KH
|KH to add to the deprecation document the requirement to announce to the community that we plan to deprecate something and to get in touch if you object.
|done 2013-12-26
|-
|[https://sourceforge.net/p/tei/feature-requests/383/ FR 383] where to put idno within biblStruct? (AMBER open) This is one of three tickets where KH could not fi...
|KH, SB
|KH will create a new ticket pointing to this and the other two tickets with deprecation problems (as listed on the wiki) saying we need a way to deprecate members of content model and reassign to SB to solve the three tickets using a Schematron warning, and to add @validUntil on constraintSpec.
|done 2013-12-08 (new ticket is at https://sourceforge.net/p/tei/feature-requests/486/)
|-
|[https://sourceforge.net/p/tei/feature-requests/482/ FR 482] The term strikes back - terminology chapter (AMBER open). The ISO is working on a standard for termi...
|LB, KH, SB
|LB, KH and SB to articulate a more generic policy for TEI on the integration of external standards and will generate a one-page proposal for this policy. This should be provided to Council ahead of the next teleconference. In addition, LB, KH, and SB will check with Laurent that he wants TBX incorporated into the Guidelines as is or kept in sync in the future and what he thinks about melding into the rest of the TEI Guidelines (in language, approach, element naming conventions) or keeping it self-contained.
|Kevin drafted a [http://www.tei-c.org/Activities/Council/Working/tcw28.xml generic policy] and circulated to Lou and Syd on 2013-12-26. Discussion of whether to incorporate TBX into the Guidelines is [http://sourceforge.net/p/tei/feature-requests/482/#28f3 happening on ticket].
|-
|[https://sourceforge.net/p/tei/feature-requests/294/ FR 294] altIdentifier is deprecated within msPart (AMBER open). Action: KH to change to Green and add to the...
|KH
|KH to change to Green and add to the ticket about deprecation using Schematron along with 383, if not already done.
|done 2013-12-08
|-
|[https://sourceforge.net/p/tei/bugs/528/ BUG 528] consistency in "the Guidelines" vs. "these Guidelines" (AMBER open). This should be green. Action: K...
|KH
|KH to do this.
|
|-
|[https://sourceforge.net/p/tei/bugs/548/ BUG 548] use of modal verbs in Guidelines (AMBER pending-later). Already assigned to KH. RW agreed to help. I...
|KH, RW, LB
|KH and RW to create a new, detailed ticket with all questionable cases. In the meantime, LB will fix the edits that KH made at r12525.
|LB commented out otiose paragraph.
|-
|[https://sourceforge.net/p/tei/bugs/216/ BUG 216] half title pages in TEI Tite (AMBER open-postponed). KH has to finish comparing TEI-Tite with the Ap...
|KH
|KH to resolve Tite problems and report regularly to Council on progress.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/280/ FR 280] clarification of colloc (GREEN pending-accepted). #1 is already done. #2: Breakout group agreed that...
|KH
|KH to remove @type from both examples, etc.
|done 2013-12-26
|-
|[https://sourceforge.net/p/tei/feature-requests/482/ FR 482] Earlier we decided:Action: LB, KH and SB to articulate a more generic policy for TEI on the integrat...
|LB, KH, SB
|LB, KH and SB to articulate a more generic policy for TEI on the integration of external standards and will generate a one-page proposal for this policy. This should be provided to Council ahead of the next teleconference. In addition, LB, KH, and SB will check with Laurent that he wants TBX incorporated into the Guidelines as is or kept in sync in the future and what he thinks about melding into the rest of the TEI Guidelines (in language, approach, element naming conventions) or keeping it self-contained.
|Kevin drafted a [http://www.tei-c.org/Activities/Council/Working/tcw28.xml generic policy] and circulated to Lou and Syd on 2013-12-26. Discussion of whether to incorporate TBX into the Guidelines is [http://sourceforge.net/p/tei/feature-requests/482/#28f3 happening on ticket].
|-
|[https://sourceforge.net/p/tei/bugs/525/ BUG 525] citedRange and biblScope should share att class (GREEN open). SB admitted to sloth. Action: SB to co...
|MH, JC, KH
|MH to check Allura settings to make sure that the owners of both bugs and feature requests receive email notifications. [JC and KH looked into this during a break and might have fixed it through another mechanism. MH to check with JC].
|n/a
|}

===Actions for Martin Holmes===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|[https://sourceforge.net/p/tei/feature-requests/453/ FR 453] a place for metadata that you can't fit into existing header elements AMBER open Discussion talks mo...
|MH, PS, LB
|MH will offer DC examples and PS will offer MARC examples. LB will pull them together into some text to be inserted into the Guidelines. Given this, Council will reconsider the feature request and whether to create the wrapper element.
|Examples provided 2013-11-20
|-
|[https://sourceforge.net/p/tei/feature-requests/471/ FR 471] extend the possible usages of argument (AMBER open). (If the intended use case is encoder-supplied a...
|LB, MH
|
|Done. Fourth example added in rev 12666 2013-11-27.
|-
|[https://sourceforge.net/p/tei/feature-requests/472/ FR 472] docDate in dateline ? EM: dateline does not allow docDate, but byline allows docAuthor. This is inco...
|MH
|MH to add docDate to dateline, and clarify with usage notes.
|Done 2013-11
|-
|[https://sourceforge.net/p/tei/feature-requests/443/ FR 443] @resp should be a member of att.global AMBER open. JC and SR: Global attributes should really not be...
|MH, LB
|MH and LB to agree on clarification to Guidelines to say that @resp means different things: responsibility for markup and content except when the element in question is a transcriptional element, in which case the content of the element is marked as coming from the source.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/303/ FR 303] check the apache logs for frequent 404s (AMBER open). Action: JC to ask DS to make the TEI-C webserv...
|JC, MH
|JC to ask DS to make the TEI-C webserver logs available somewhere we can see them; then action on MH to write script to generate lists of bad links of various types. JC also to check google analytics/Webmaster tools. Deadline to report back by next conference call.
|I've checked through the logs, which the webmaster provided for me. There seem to be no instances of systematic errors. There seems to be little to gain from this, assuming the sysadmins are already routine monitoring.
|-
|[https://sourceforge.net/p/tei/feature-requests/470/ FR 470] att.measurement and att.dimensions overlap (AMBER open). We are not really sure why all of these att...
|MH
|MH to move @commodity into its own class, and move measure and measureGrp to att.dimensions. Ticket to GREEN, assign to MH. [Subsequent study suggests to MH that this may be more complicated than it seems, and may have to wait on our having the ability to override valLists in attributes from attribute classes at the element level.]
|Set back to Amber pending further discussion. See ticket for details.
|-
|[http://wiki.tei-c.org/index.php/Council_agenda_2013-11#More_Details_on_Agenda_topics bottom of wiki agenda page] ) SR: Why are we proposing using alpha and beta? MH: Because we were proposing asking the community ...
|MH, SR
|Assign MH to update the release documentation re alpha and beta, and investigate how we might add the SVN last changed date and the rev number to the bottom of pages.
|Latter bit done by SR 2013-11-14. Documentation in TCW22 updated by MH 2013-11-14.
|-
|[https://sourceforge.net/p/tei/feature-requests/405/ FR 405] Wrong schema generated (AMBER pending-accepted). This is due to a bug in the current version in Roma...
|MH
|MH to see if it has been fixed, and if so, close the ticket.
|Done 2013-11
|-
|[https://sourceforge.net/p/tei/feature-requests/342/ FR 342] [http://wiki.tei-c.org/index.php/Text_Directionality_Draft first draft of new Guidelines sections] and questions [MH] MH summarized the genesis of this text from Providence.
|MH, LB
|Entire Council to (re)read MH’s draft before next face-to-face meeting. Once we’ve done that and agreed, someone will rewrite chapter 5 (WD) to include MH’s draft and the current section 10.6.6. LB volunteered.
|Council and the WG members have been asked to read and comment on the draft (2013-11-28).
|-
|[https://sourceforge.net/p/tei/bugs/578/ BUG 578] partial and recursive segmentation of s-units (AMBER open). [The Guidelines text is clear enough. Th...
|MH
|MH will revise content model to match the prose.
|Done 2013-11-27, although I really don't like the results of this.
|-
|[https://sourceforge.net/p/tei/feature-requests/298/ BUG 298] att.editLike should not bring att.dimensions & att.ranging (AMBER open-accepted). [MH to ask Gabriel...
|MH
|MH to ask Gabby to implement.
|GB has asked to pass the ticket to MH (2013-11-28). MH to create a full proposal and implement if approved.
|-
|[https://sourceforge.net/p/tei/feature-requests/212/ FR 212] Generic dating class (AMBER pending-accepted). Gabby claimed in 2011 that it’s done except needs som...
|HC, MH
|HC to investigate whether it’s actually been done. MH offered examples if needed.
|Hugh has opened a new bug [https://sourceforge.net/p/tei/bugs/635/ #635] to address this.
|-
|[https://sourceforge.net/p/tei/bugs/568/ BUG 568] "How to edit the Guidelines" and chapter organization (AMBER open). SR: What MH found looks distinct...
|MH
|MH to replace references to entity references with explanation of XIncludes in “How to edit the Guidelines”.
|Done 2013-11
|-
|[https://sourceforge.net/p/tei/bugs/506/ BUG 506] Meaning of @corresp rather in dispute (AMBER open). Working group triage: needs to be discussed: Is ...
|MH
|MH to create an example and run it by tei-council before adding to the Guidelines.
|Done 2013-12-23
|-
|[https://sourceforge.net/p/tei/bugs/582/ BUG 582] Need for consistency in terminology relating to TEI conformance (AMBER open). Working group: Agreed ...
|MH
|MH to deal with the ticket narrowly, using a hyphen and lowercase but leaving both “conformant” and “conformable”.
|Done 2013-11-20
|-
|[https://sourceforge.net/p/tei/bugs/460/ BUG 460] list/@type="unordered" is not recommended, but used often (AMBER open). Working group: This bug has...
|MH
|MH to follow the last comment on ticket to figure out our current situation.
|Research done, and a proposal being developed [http://wiki.tei-c.org/index.php/List_types_and_rendering on the wiki].
|-
|[https://sourceforge.net/p/tei/bugs/581/ BUG 581] `attRef` needs better documentation (AMBER open). Action: SR to implement either removal of attRef, ...
|SR, MH
|SR to implement either removal of attRef, MH to adjust documentation.
|SR recommends holding off on documentation because he may be able to eliminate attRef in favour of classRef.
|-
|[https://sourceforge.net/p/tei/feature-requests/432/ FR 432] Change regex flavor on @matchPattern (GREEN open). Agreed, XPath. Action: MH Write to TEI-L list, if...
|MH
|MH Write to TEI-L list, if no negative feedback, change.
|Done 2013-11-21 rev 12660
|-
|[https://sourceforge.net/p/tei/bugs/312/ BUG 312] i18n revision due (GREEN open). Action: MH, when he completes action on related ticket (perhaps afte...
|MH
|MH, when he completes action on related ticket (perhaps after moving notes from minutes into tickets), to update this ticket.
|Some contacts made with potential translators 2013-12; suggestion for a pilot project with Italian and Chinese posted to Council list.
|-
|[https://sourceforge.net/p/tei/bugs/442/ BUG 442] update ODD documentation on www.tei-c.org and in Guidelines (GREEN open). Action: MH to finish it....
|MH
|MH to finish it.
|
|-
|[https://sourceforge.net/p/tei/bugs/441/ BUG 441] fDecl doesn't allow att.datcat yet (GREEN open-accepted). Action: MH to prod Piotr....
|MH
|MH to prod Piotr.
|Piotr prodded 2013-11-21, and twice more after that.
|-
|[https://sourceforge.net/p/tei/bugs/525/ BUG 525] citedRange and biblScope should share att class (GREEN open). SB admitted to sloth. Action: SB to co...
|MH, JC, KH
|MH to check Allura settings to make sure that the owners of both bugs and feature requests receive email notifications. [JC and KH looked into this during a break and might have fixed it through another mechanism. MH to check with JC].
|According to investigation, we've done what we can with Allura settings here.
|}

===Actions for Elli Mylonas===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|Ideas on how to run an experimental TEI Hackathon [SR]

|JC, HC, SR, EM
|JC to approach the DH 2014 committee and find out how they would prefer us to do it, and whether it’s a good idea; and tell the Board that HC, SR and EM are prepared to be involved in organizing this along with one or more Board members.
|JC did, hand off to EM Jan 9 '14 DONE
|-
|Ideas on how to run an experimental TEI Hackathon [SR]

|EM
|EM to make sure this happens.
|Jan 28 '14 Discussions begun, proposal draft begun. Feb 21 proposal submitted to DH2014 DONE
|-
|[https://sourceforge.net/p/tei/feature-requests/300/ FR 300] Move witStart et al. to model.milestoneLike (AMBER pending). Action: EM to change to red and assigne...
|EM
|EM to change to red and assigned to EM to chase up or otherwise close ticket.
|
|-
|[https://sourceforge.net/p/tei/bugs/594/ BUG 594] TEI-C website menu points to wrong index page for Guidelines (AMBER open). Fixed, will appear in nex...
|EM
|EM to create a ticket on the Chrome problem.
|Dec 10, 2013 done
|-
|[https://sourceforge.net/p/tei/bugs/589/ BUG 589] add respons and space to att.responsibility (AMBER open). Working group triage: Is it ok to add have...
|EM
|EM will get rid of locally assigned @resp by adding to att.responsibility (thereby getting @cert as well). Will change to GREEN.
|Dec 10, 2013 Done
|-
|[https://sourceforge.net/p/tei/bugs/563/ BUG 563] inconsistent encoding of citations to sources of examples (AMBER open). Working group recommends ass...
|BB, EM, PS
|BB, EM, and PS to work on the ticket by mid-February 2014.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/389/ FR 389] clarify definition of @from on locus and biblScope (GREEN open). EM admits to sloth and will do so. ...
|EM
|EM to do before next teleconference.
|
|-
|[http://wiki.tei-c.org/index.php/TEI_Cheatsheets Cheatsheets: Short best/recommended practice documents] EM: Not cheatsheets - negative implication. RW: Quick Start. HC: Quick Reference; SB: “Guidelettes” ...
|EM
|EM to ask MB to clarify what she wants from Council with regard to helping cheatsheets.
|
|}

===Actions for Sebastian Rahtz===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|[http://tei.oucs.ox.ac.uk/EEBO/ http://tei.oucs.ox.ac.uk/EEBO/] for summary of problem, and links to tickets) SR: EEBO-TCP is a gigantic resource that claims to be ...
|SR
|SR will implement the schema change of adding @place to stage and will document and provide an example.
|adding @place. example to do
|-
|[https://sourceforge.net/p/tei/feature-requests/479/ FR 479] Adding the @place attribute to head and seg AMBER open JC noted that head is not meta-textual or in ...
|SR
|SR to take the ticket, and get more examples from the submitter
|DONE
|-
|[https://sourceforge.net/p/tei/feature-requests/445/ FR 445] Conversion of ODD to HTML: Examples should be aware of element renaming closed-fixed, implemented by...
|SR
|SR to add gi and att renaming to complete the ticket.
| COMPLETED FOR gi. Not possible for att.
|-
|[https://sourceforge.net/p/tei/feature-requests/442/ FR 442] Allow foreign to contain q (AMBER open). The group felt this should be rejected. Action:SR to close ...
|SR
|SR to close ticket because it’s rejected
|DONE
|-
|[https://sourceforge.net/p/tei/feature-requests/433/ FR 433] loosen content model of salute (AMBER open). SR: Underlying this was a desire for symmetry between s...
|SR
|SR will carry this out
|DONE
|-
|[https://sourceforge.net/p/tei/feature-requests/477/ FR 477] lines of poetry inside trailer (AMBER open). The request is for symmetry between head and trailer. T...
|SR
|SR to find a good way to achieve this, since what was done before with head was rather strange.
|DONE. Have copied what was done with head
|-
|[https://sourceforge.net/p/tei/feature-requests/383/ FR 383] where to put idno within biblStruct? (AMBER open) This is one of three tickets where KH could not fi...
|SR
|SR to check how @validUntil makes the build fail when out of date, and if necessary update this mechanism so it can handle @validUntil on constraintSpec. Ticket 383 will wait on all this, along with the two other tickets.
|DONE. It applies to tei:*[@validUntil], so should just work.] .
|-
|[http://wiki.tei-c.org/index.php/Council_agenda_2013-11#More_Details_on_Agenda_topics bottom of wiki agenda page] ) SR: Why are we proposing using alpha and beta? MH: Because we were proposing asking the community ...
|MH, SR
|Assign MH to update the release documentation re alpha and beta, and investigate how we might add the SVN last changed date and the rev number to the bottom of pages.
|Latter bit done by SR 2013-11-14. Documentation in TCW22 updated by MH 2013-11-14.]
|-
|Ideas on how to run an experimental TEI Hackathon [SR]
|JC, HC, SR, EM
|JC to approach the DH 2014 committee and find out how they would prefer us to do it, and whether it’s a good idea; and tell the Board that HC, SR and EM are prepared to be involved in organizing this along with one or more Board members.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/345/ FR 345] members of model.respLike should be members of att.declarable (AMBER open-later). Breakout group ins...
|SR
|SR to make the ticket Green and go ahead and implement it, including some documentation/examples.
|DONE
|-
|[https://sourceforge.net/p/tei/bugs/302/ BUG 302] version ignores @source (AMBER open). This is a Roma issue. Recommend marking as closed won’t fix be...
|SR
|SR to try reproducing this and set as closed-won’t fix.
|DONE
|-
|[https://sourceforge.net/p/tei/bugs/583/ BUG 583] Adding new attribute fails in Roma schema generation (AMBER open). Same as 302. Action: SR wil set a...
|SR
|SR wil set as closed-won’t fix and check that it has the Roma tag.
|DONE
|-
|[https://sourceforge.net/p/tei/bugs/434/ BUG 434] issues with ePub conversion (2/3) (AMBER open). Any issue not dealing with ODD processing should be ...
|SR
|SR will ask poster kindly to post there (explaining why) and close this issue.
|DONE
|-
|[https://sourceforge.net/p/tei/bugs/581/ BUG 581] `attRef` needs better documentation (AMBER open). Action: SR to implement either removal of attRef, ...
|SR, MH
|SR to implement either removal of attRef, MH to adjust documentation.
|FIxed attRef. thinking about classRef. some changes made to implementation of that. attRef still needed.
|-
|[https://sourceforge.net/p/tei/feature-requests/467/ FR 467] Make @name optional on tei:relation (GREEN open). Action: SR has already done this....
|SR
|SR to action
|DOne
|-
|[https://sourceforge.net/p/tei/feature-requests/478/ FR 478] loosening content and model of `signed` (GREEN open). Agree that is is green. Though would model.div...
|SR
|SR to implement signed at top as well as bottom
|DONE
|}

===Actions for Paul Schaffner===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|[https://sourceforge.net/p/tei/feature-requests/453/ FR 453] a place for metadata that you can't fit into existing header elements AMBER open Discussion talks mo...
|MH, PS, LB
|MH will offer DC examples and PS will offer MARC examples. LB will pull them together into some text to be inserted into the Guidelines. Given this, Council will reconsider the feature request and whether to create the wrapper element.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/360/ FR 360] New attribute @keepHyphen. Ticket open, ticket GREEN, it’s rejected throughout the comments....
|PS
|PS to provide an example of the mechanism recommended to handle the use-case.
|
|-
|[https://sourceforge.net/p/tei/bugs/563/ BUG 563] inconsistent encoding of citations to sources of examples (AMBER open). Working group recommends ass...
|BB, EM, PS
|BB, EM, and PS to work on the ticket by mid-February 2014.
|
|-
|[https://sourceforge.net/p/tei/bugs/558/ BUG 558] name/orgName (AMBER open). Action: RW to ask PS where he is on this; change ticket status to GREEN....
|RW, PS
|RW to ask PS where he is on this; change ticket status to GREEN.
|
|}

===Actions for Torsten Schassan===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|

|TS
|TS to come up with a more detailed problem description and what the WG should attempt to solve by 2014-01-01.
|
|}

===Actions for Rebecca Welzenbach===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|[https://sourceforge.net/p/tei/feature-requests/384/ FR 384] : In April RW made a spreadsheet showing which elements she recommends moving into att.typed. And in...
|SB, RW
|SB and RW will review the list again.
|
|-
|Attributes without examples

|BB, RW
|BB and RW to turn into bug reports those attributes that are without examples that are high priority or need new/updated definitions.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/377/ FR 377] retaining punctuation marks in the text of a TEI document (AMBER open-accepted). RW says she has add...
|RW
|RW to finish the work and ask for help if necessary.
|
|-
|[https://sourceforge.net/p/tei/bugs/548/ BUG 548] use of modal verbs in Guidelines (AMBER pending-later). Already assigned to KH. RW agreed to help. I...
|KH, RW, LB
|KH and RW to create a new, detailed ticket with all questionable cases. In the meantime, LB will fix the edits that KH made at r12525.
|
|-
|[https://sourceforge.net/p/tei/bugs/558/ BUG 558] name/orgName (AMBER open). Action: RW to ask PS where he is on this; change ticket status to GREEN....
|RW, PS
|RW to ask PS where he is on this; change ticket status to GREEN.
|
|-
|[https://sourceforge.net/p/tei/bugs/401/ BUG 401] Most attributes lack good examples (GREEN open-accepted). This was previously discussed. Action: RW ...
|RW
|RW to follow up.
|
|}

[[Category:Council]]

Council agenda 2014-01

2014-01-09T12:35:18Z

Rahtz: /* TEI Council Agenday 2014-01 */

== TEI Council Agenday 2014-01 ==
* Review of Actions [JC] Please Update [[Oxford2013-Actions2]] with state of actions. Need to review action lists of ex-members.
* Next Release (anything blocking?)
* Board Report [JC]
* Council membership [JC]
* Face to Face Meetings [JC]
* TEI Simple project [SR]
*
* Add agenda items here

Council agenda 2014-01

2014-01-09T12:33:53Z

Rahtz: /* TEI Council Agenday 2014-01 */

== TEI Council Agenday 2014-01 ==
* Review of Actions [JC] Please Update [[Oxford2013-Actions2]] with state of actions.
* Next Release (anything blocking?)
* Board Report [JC]
* Council membership [JC]
* Face to Face Meetings [JC]
* TEI Simple project [SR]
*
* Add agenda items here

ODD

2013-12-16T13:12:45Z

Rahtz: /* Example */

'''ODD''' stands for "One Document Does it all". It is a TEI XML-conformant specification format that allows one to customize TEI P5 in a [[Wikipedia:literate programming|literate programming]] fashion. It uses elements from the new [http://www.tei-c.org/P5/Guidelines/TD.html Documentation Elements] module.

== Description ==
The TEI Guidelines, its DTD, and its schema fragments, are all produced from a single XML resource containing:

# Descriptive prose (lots of it)
# Examples of usage (plenty)
# Formal declarations for components of the TEI Abstract Model:
## elements and attributes
## modules
## classes and macros

We call this resource an ODD (One Document Does it all), although the master source is instantiated as a gazillion XML mini-documents.

A system of XSLT stylesheets called [[Roma]] has been created for the purpose of easy manipulation of ODD files.

== Example ==
The TEI scheme can only be used by customizing it. Customizations are also expressed in the ODD language. For example:

<pre>
<schemaSpec ident="myTEIlite">
<desc>This is TEI Lite with simplified heads</desc>
<moduleRef key="tei"/>
<moduleRef key="textstructure"/>
<moduleRef key="linking"/>
<moduleRef key="core"/>
<moduleRef key="header"/>
<elementSpec ident="head" mode="change">
<content><rng:text/></content>
</elementSpec>
</schemaSpec>
</pre>

produces the schema a bit like TEI Lite, with a slight change.

== Uses besides the TEI Guidelines and various customizations ==

* [http://www.w3.org/TR/its/ Internationalization Tag Set (ITS)]
* various standards proposal designed within ISO committee TC 37 have been totally or partially written in TEI/ODD: MLIF, MAF, ISO 16642 rev., ISOTimeML

== Future plans ==

Over the years ODD has evolved progressively to reflect more and more needs of the TEI community, both as the core specification language for the TEI guidelines, but also as generic customization language for any TEI users. Still ODD remains a hybrid environment combining its own vacabulary with RelaxNG fragments and at times, validation vocabularies from external languages (e.g. Schematron). The TEI council contemplates putting on its work program a revision of the ODD infrastructure, considering either to drop it altogether in favor of one existing schema language, or extend its capabilities to make it a self contained and generic specification language. Some thoughts are included at [[ODD-dev]].

== See also ==
*[http://en.wikipedia.org/wiki/ODD_%28Text_Encoding_Initiative%29 ODD (Text Encoding Initiative)] in Wikipedia
*[[ODD-dev]]
=== Documentation ===
*[http://www.tei-c.org/Guidelines/Customization/odds.xml Getting Started with P5 ODDs]
*[http://www.w3.org/TR/xml-i18n-bp/#tei-modularization A fragment of W3C's Best Practices for XML Internationalization concerning ODD customization for the Internationalization Tag Set (ITS).]
=== Presentations ===
*[http://tei.oucs.ox.ac.uk/Oxford/2007-02-13-oucs/talk-odds.xml A talk about the ODD system], given on 13 Feb 2007 by Lou Burnard and Sebastian Rahtz at the OUCS ''Encoding Digital Texts'' workshop
*[http://tei.oucs.ox.ac.uk/Oxford/2006-09-methNet/Talks/RomaJourney.ppt A PowerPoint presentation on TEI/ODD] by Laurent Romary; OUCS, September 2006
*[http://www.balisage.net/Proceedings/vol7/html/Banski01/BalisageVol7-Banski01.html Literate serialization of linguistic metamodels] by Piotr Bański, Balisage-2011

=== Articles ===
* [http://conferences.idealliance.org/extreme/html/2004/Bauman01/EML2004Bauman01.html Odd Customizations], by Syd Bauman and Julia Flanders.
* [http://conferences.idealliance.org/extreme/html/2004/Burnard01/EML2004Burnard01.html RelaxNG with Son of ODD], by Lou Burnard and Sebastian Rahtz.
* [http://www.balisage.net/Proceedings/vol1/html/Bauman01/BalisageVol1-Bauman01.html Freedom to Constrain] by Syd Bauman

[[Category:Customization|!]]

Oxford2013-Actions2

2013-11-21T17:43:57Z

Rahtz: /* Actions for Sebastian Rahtz */

==Council Actions from November 2013 Oxford Meeting==

A list of actions, those responsible, and what has been done about them from Oxford 2013 face to face meeting of TEI Technical Council

===Actions for Brett Barney===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|Attributes without examples

|BB, RW
|BB and RW to turn into bug reports those attributes that are without examples that are high priority or need new/updated definitions.
|
|-
|[https://sourceforge.net/p/tei/bugs/563/ BUG 563] inconsistent encoding of citations to sources of examples (AMBER open). Working group recommends ass...
|BB, EM, PS
|BB, EM, and PS to work on the ticket by mid-February 2014.
|
|-
|[https://sourceforge.net/p/tei/bugs/610/ BUG 610] "lem" used in a confusing way in CriticalApparatus.xml (AMBER open). Action: BB to remove the last c...
|BB
|BB to remove the last clause of the sentence in question, beginning ", or to make clear".
|
|-
|[https://sourceforge.net/p/tei/bugs/387/ BUG 387] clarifying heading or title of a graphic (GREEN open). LB recently posted a comment approving of the...
|BB
|BB will implement the ticket.
|
|}

===Actions for Lou Burnard===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|[https://sourceforge.net/p/tei/feature-requests/457/ FR 457] : KH: In the ticket I want to clarify what you use tagUsage for and what to put in a project-specifi...
|KH, LB, JC
|KH, LB, and JC will review and make a recommendation to Council before the next face-to-face.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/453/ FR 453] a place for metadata that you can't fit into existing header elements AMBER open Discussion talks mo...
|MH, PS, LB
|MH will offer DC examples and PS will offer MARC examples. LB will pull them together into some text to be inserted into the Guidelines. Given this, Council will reconsider the feature request and whether to create the wrapper element.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/471/ FR 471] extend the possible usages of argument (AMBER open). (If the intended use case is encoder-supplied a...
|LB, MH
|
|
|-
|Pure ODD

|LB
|LB to add the new elements and the documentation ahead of the next release; documentation need only be at the element level, along with some brief introduction in the Guidelines, to be expanded to a full section later.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/443/ FR 443] @resp should be a member of att.global AMBER open. JC and SR: Global attributes should really not be...
|MH, LB
|MH and LB to agree on clarification to Guidelines to say that @resp means different things: responsibility for markup and content except when the element in question is a transcriptional element, in which case the content of the element is marked as coming from the source.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/366/ FR 366] rationalize content models of org and place (etc) (AMBER open). Group thinks a small group of people...
|JC, LB, SB
|JC to make ticket red, should stay with JC, and he should initiate the process, working with LB and SB.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/458/ FR 458] Make listBibl and model.biblLike member of model.personPart (AMBER open). Lou has already done items...
|LB
|close the ticket.
|
|-
|i18n: take forward updating translations

|LB
|LB to testdrive the spreadsheet.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/482/ FR 482] The term strikes back - terminology chapter (AMBER open). The ISO is working on a standard for termi...
|LB, KH, SB
|LB, KH and SB to articulate a more generic policy for TEI on the integration of external standards and will generate a one-page proposal for this policy. This should be provided to Council ahead of the next teleconference. In addition, LB, KH, and SB will check with Laurent that he wants TBX incorporated into the Guidelines as is or kept in sync in the future and what he thinks about melding into the rest of the TEI Guidelines (in language, approach, element naming conventions) or keeping it self-contained.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/480/ FR 480] Adding the @hand attribute to all (or most) text-containing elements (AMBER open). Breakout group wa...
|LB
|LB to respond to the ticket FR 480.
|
|-
|[http://wiki.tei-c.org/index.php/Text_Directionality_Draft first draft of new Guidelines sections] and questions [MH] MH summarized the genesis of this text from Providence. He noted that not only th...
|MH, LB
|Entire Council to (re)read MH’s draft before next face-to-face meeting. Once we’ve done that and agreed, someone will rewrite chapter 5 (WD) to include MH’s draft and the current section 10.6.6. LB volunteered.
|
|-
|[https://sourceforge.net/p/tei/bugs/548/ BUG 548] use of modal verbs in Guidelines (AMBER pending-later). Already assigned to KH. RW agreed to help. I...
|KH, RW, LB
|KH and RW to create a new, detailed ticket with all questionable cases. In the meantime, LB will fix the edits that KH made at r12525.
|
|-
|[https://sourceforge.net/p/tei/bugs/468/ BUG 468] Order of elements in publicationStmt (AMBER open-accepted). Group discussion: SB: Despite Lou’s comm...
|SB, LB
|SB will do the content model and LB will do the prose. They’ll work out the specifics.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/469/ FR 469] add extent to att.dimensions (GREEN open). Agreed. Action: LB to provide an example in HD chapter (2...
|LB
|LB to provide an example in HD chapter (2.2.3) and close ticket.
|
|-
|[https://sourceforge.net/p/tei/bugs/605/ BUG 605] clarifying add vs. supplied and del vs. surplus (AMBER open). Action: HC to emend the prose of the p...
|HC, LB
|HC to emend the prose of the paragraph beginning "The add element should not be used" to reference the surplus element also; LB points out that the specList can't be modified, because supplied/surplus aren't defined in Core.
|
|-
|[https://sourceforge.net/p/tei/bugs/609/ BUG 609] "lemma" used in a confusing way in CriticalApparatus.xml (AMBER open). Action: LB to remove the phra...
|LB
|LB to remove the phrase "on any one lemma" from the @varSeq description.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/461/ FR 461] Two small improvements to `recording` (GREEN open). Action: LB to do this by next teleconference....
|LB
|LB to do this by next teleconference.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/482/ FR 482] Earlier we decided:Action: LB, KH and SB to articulate a more generic policy for TEI on the integrat...
|LB, KH, SB
|LB, KH and SB to articulate a more generic policy for TEI on the integration of external standards and will generate a one-page proposal for this policy. This should be provided to Council ahead of the next teleconference. In addition, LB, KH, and SB will check with Laurent that he wants TBX incorporated into the Guidelines as is or kept in sync in the future and what he thinks about melding into the rest of the TEI Guidelines (in language, approach, element naming conventions) or keeping it self-contained.
|
|-
|Correspondence SIG:

|SB, LB
|SB and LB would like to (re?-)join the task force. Council advises them to keep in mind the work by the Ontology/MS SIGs, in particular Torsten Schassan, on an ‘object’ or ‘objectDesc’ element.
|
|}

===Actions for Syd Bauman===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|[https://sourceforge.net/p/tei/feature-requests/384/ FR 384] : In April RW made a spreadsheet showing which elements she recommends moving into att.typed. And in...
|SB, RW
|SB and RW will review the list again.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/459/ FR 459] : This is just waiting for implementation....
|SB
|SB will implement by end of January 2014.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/481/ FR 481] check that all sibling att.translatable elements have @versionDate (AMBER open). (Agreed that siblin...
|SB
|SB to check whether this is implemented, and if not, get it implemented then close the ticket.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/468/ FR 468] : HC: precision expresses false precision that’s not real probability. It’s something more like cert...
|SB
|
|
|-
|[https://sourceforge.net/p/tei/feature-requests/383/ FR 383] where to put idno within biblStruct? (AMBER open) This is one of three tickets where KH could not fi...
|KH, SB
|KH will create a new ticket pointing to this and the other two tickets with deprecation problems (as listed on the wiki) saying we need a way to deprecate members of content model and reassign to SB to solve the three tickets using a Schematron warning, and to add @validUntil on constraintSpec.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/366/ FR 366] rationalize content models of org and place (etc) (AMBER open). Group thinks a small group of people...
|JC, LB, SB
|JC to make ticket red, should stay with JC, and he should initiate the process, working with LB and SB.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/482/ FR 482] The term strikes back - terminology chapter (AMBER open). The ISO is working on a standard for termi...
|LB, KH, SB
|LB, KH and SB to articulate a more generic policy for TEI on the integration of external standards and will generate a one-page proposal for this policy. This should be provided to Council ahead of the next teleconference. In addition, LB, KH, and SB will check with Laurent that he wants TBX incorporated into the Guidelines as is or kept in sync in the future and what he thinks about melding into the rest of the TEI Guidelines (in language, approach, element naming conventions) or keeping it self-contained.
|
|-
|[https://sourceforge.net/p/tei/bugs/276/ BUG 276] internationalisation links (AMBER open). Language links at bottom of a page should take you to same ...
|JC, SB
|JC to make Green and allocate to SB.
|
|-
|[https://sourceforge.net/p/tei/bugs/619/ BUG 619] tei_allPlus.rng: conflicting ID-types for attribute "id" of element "partialdiff" from namespace "ht...
|SB
|SB to double-check whether able to reproduce and report back on ticket if able to.
|
|-
|[https://sourceforge.net/p/tei/bugs/288/ BUG 288] deprecate use of gram except as a child of gramGrp (AMBER open-accepted). [This is pending creation ...
|SB
|SB to create the new ticket and write the Schematron for this particular deprecation.
|
|-
|[https://sourceforge.net/p/tei/bugs/468/ BUG 468] Order of elements in publicationStmt (AMBER open-accepted). Group discussion: SB: Despite Lou’s comm...
|SB, LB
|SB will do the content model and LB will do the prose. They’ll work out the specifics.
|
|-
|[https://sourceforge.net/p/tei/bugs/405/ BUG 405] XPointer schemes may not nest, but see ch. 16 (AMBER open). Action: SB to fix documentation....
|SB
|SB to fix documentation.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/482/ FR 482] Earlier we decided:Action: LB, KH and SB to articulate a more generic policy for TEI on the integrat...
|LB, KH, SB
|LB, KH and SB to articulate a more generic policy for TEI on the integration of external standards and will generate a one-page proposal for this policy. This should be provided to Council ahead of the next teleconference. In addition, LB, KH, and SB will check with Laurent that he wants TBX incorporated into the Guidelines as is or kept in sync in the future and what he thinks about melding into the rest of the TEI Guidelines (in language, approach, element naming conventions) or keeping it self-contained.
|
|-
|[http://sourceforge.net/p/tei/feature-requests/378/ FR 378] ; c.f. A Generic Formalism for Encoding Standoff annotations in TEI). Action: JC to ask Peter Stadle...
|JC, HC, SB
|JC to ask Peter Stadler if he’d like to attend as Council rep; otherwise any interested members of Council (HC,SB) are encouraged to attend virtually.
|
|-
|Correspondence SIG:

|SB, LB
|SB and LB would like to (re?-)join the task force. Council advises them to keep in mind the work by the Ontology/MS SIGs, in particular Torsten Schassan, on an ‘object’ or ‘objectDesc’ element.
|
|-
|[https://sourceforge.net/p/tei/bugs/525/ BUG 525] citedRange and biblScope should share att class (GREEN open). SB admitted to sloth. Action: SB to co...
|SB
|SB to complete.
|
|}

===Actions for Hugh Cayless===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|Report on specification and estimated cost for XPointer resolver [HC/SB]

|HC
|HC to report on XPointer resolver and whether we should progress it.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/465/ FR 465] : Gabby and HC seem to agree on it, and the example looks sensible. LB’s comment could be raised as ...
|HC
|HC will implement before end of January 2014.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/384/ FR 384] that once 384 is implemented, we’ll add a note on att.typed reminding people that this is meant for ...
|HC, KH
|HC will implement [DONE]. KH will add a comment to FR 384 [DONE].
|
|-
|[https://sourceforge.net/p/tei/feature-requests/462/ FR 462] idno@type='uri' for Linked Data AMBER open (We agreed. @type=”URI” alongside @type=”URL”) EM: The su...
|HC
|HC to implement this and close the ticket FR 462.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/468/ FR 468] : HC: precision expresses false precision that’s not real probability. It’s something more like cert...
|HC
|HC to email TEI-L.
|
|-
|Ideas on how to run an experimental TEI Hackathon [SR]

|JC, HC, SR, EM
|JC to approach the DH 2014 committee and find out how they would prefer us to do it, and whether it’s a good idea; and tell the Board that HC, SR and EM are prepared to be involved in organizing this along with one or more Board members.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/212/ FR 212] Generic dating class (AMBER pending-accepted). Gabby claimed in 2011 that it’s done except needs som...
|HC, MH
|HC to investigate whether it’s actually been done. MH offered examples if needed.
|
|-
|[https://sourceforge.net/p/tei/bugs/605/ BUG 605] clarifying add vs. supplied and del vs. surplus (AMBER open). Action: HC to emend the prose of the p...
|HC, LB
|HC to emend the prose of the paragraph beginning "The add element should not be used" to reference the surplus element also; LB points out that the specList can't be modified, because supplied/surplus aren't defined in Core.
|
|-
|[http://sourceforge.net/p/tei/feature-requests/378/ FR 378] ; c.f. A Generic Formalism for Encoding Standoff annotations in TEI). Action: JC to ask Peter Stadle...
|JC, HC, SB
|JC to ask Peter Stadler if he’d like to attend as Council rep; otherwise any interested members of Council (HC,SB) are encouraged to attend virtually.
|
|}

===Actions for James Cummings===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|[https://sourceforge.net/p/tei/feature-requests/457/ FR 457] : KH: In the ticket I want to clarify what you use tagUsage for and what to put in a project-specifi...
|KH, LB, JC
|KH, LB, and JC will review and make a recommendation to Council before the next face-to-face.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/476/ FR 476] use of stage inside poetry, and using placement attribute (AMBER open). (Council agreed to @place; s...
|JC
|JC to close ticket FR 476 noting it has been resolved.
|
|-
|[https://docs.google.com/document/d/1766WTJV2xcfANh8HRZW5m520yrC1nCzQJzUgKpwiylI/edit TEI Roma Replacement Specification] JC: The existing Roma is dated and flawed, as we all know. Many tickets have come up which we cannot...
|JC
|ALL Council to go through the proposal again and discuss it, remembering to look at the comments, and further refine it. JC to make sure it’s tidied up. Deadline: next teleconference.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/303/ FR 303] check the apache logs for frequent 404s (AMBER open). Action: JC to ask DS to make the TEI-C webserv...
|JC, MH
|JC to ask DS to make the TEI-C webserver logs available somewhere we can see them; then action on MH to write script to generate lists of bad links of various types. JC also to check google analytics/Webmaster tools. Deadline to report back by next conference call.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/305/ FR 305] Updating info on projects page (AMBER open). Project pages go out of date. There is a way to submit ...
|JC
|JC to ask DS to make that correction info available on each project page, along with its last-updated date if possible (and the latter should also show up on the bullet-point list).
|
|-
|[https://sourceforge.net/p/tei/feature-requests/466/ FR 466] Make it possible to add SIG labels to tickets (AMBER open). Action: JC as SIG Coordinator to tell th...
|JC
|JC as SIG Coordinator to tell the SIGs that if they wish, we can make their SIG convener a developer on SF and make it possible to assign SIG labels to tickets. Deadline: next teleconference.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/366/ FR 366] rationalize content models of org and place (etc) (AMBER open). Group thinks a small group of people...
|JC, LB, SB
|JC to make ticket red, should stay with JC, and he should initiate the process, working with LB and SB.
|
|-
|Ideas on how to run an experimental TEI Hackathon [SR]

|JC, HC, SR, EM
|JC to approach the DH 2014 committee and find out how they would prefer us to do it, and whether it’s a good idea; and tell the Board that HC, SR and EM are prepared to be involved in organizing this along with one or more Board members.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/264/ FR 264] altIdentifier in msPart (AMBER pending-accepted). Action: JC to change to Green and assign to himsel...
|JC
|JC to change to Green and assign to himself, then nudge Torsten for an example of an altIdentifier within an msPart.
|
|-
|[https://sourceforge.net/p/tei/bugs/276/ BUG 276] internationalisation links (AMBER open). Language links at bottom of a page should take you to same ...
|JC, SB
|JC to make Green and allocate to SB.
|
|-
|[https://sourceforge.net/p/tei/bugs/515/ BUG 515] Bad example of feature/@fVal (AMBER open). [Change this to RED as it’s not clear what needs changin...
|JC
|JC to check that’s been changed to RED [DONE].
|
|-
|[https://sourceforge.net/p/tei/bugs/582/ BUG 582] Need for consistency in terminology relating to TEI conformance (AMBER open). Working group: Agreed ...
|JC
|JC will create a ticket to reconsider the discussion of “conformable” and “conformant” in the Guidelines.
|
|-
|[https://sourceforge.net/p/tei/bugs/601/ BUG 601] att.patternReplacement/@matchPattern should be XPath regex, not XML Schema (AMBER open). Action: JC ...
|JC
|JC to close as a dupe of FR 432.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/460/ FR 460] Use of geogFeat in transcription? (GREEN open). Ok. Action: JC to do it before next teleconference....
|JC
|JC to do it before next teleconference.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/474/ FR 474] add an exemplum for @ref (GREEN open). Action: JC to poke JC; deadline by next teleconference....
|JC
|JC to poke JC; deadline by next teleconference.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/475/ FR 475] Stop using attributes to store space-delimited values (GREEN open). Nothing wrong with space-delimit...
|JC
|JC to Close as Closed-rejected.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/401/ FR 401] extend and clarify use of particDesc and settingDesc (GREEN open). JC admits sloth and will implemen...
|JC
|JC to implement before next teleconference; Council decides it might be better to add these (model.
|
|-
|[http://sourceforge.net/p/tei/feature-requests/378/ FR 378] ; c.f. A Generic Formalism for Encoding Standoff annotations in TEI). Action: JC to ask Peter Stadle...
|JC, HC, SB
|JC to ask Peter Stadler if he’d like to attend as Council rep; otherwise any interested members of Council (HC,SB) are encouraged to attend virtually.
|
|-
|[https://sourceforge.net/p/tei/bugs/229/ BUG 229] Check desc of all xs:anyURI atts for in-doc restrictions (GREEN pending). We got rid of data.code al...
|JC
|JC to check prose discussion all xsd:anyURI attributes by next teleconference.
|
|-
|[https://sourceforge.net/p/tei/bugs/336/ BUG 336] AdBlock blocks 'msad' ID (GREEN pending-later). Per last comment, time has passed and nothing else h...
|JC
|JC to close ticket.
|
|-
|[https://sourceforge.net/p/tei/bugs/587/ BUG 587] Guidelines version info on pages should link better (GREEN open). Action: JC to carry out his last c...
|JC
|JC to carry out his last comment on the ticket.
|
|-
|[https://sourceforge.net/p/tei/bugs/519/ BUG 519] Make lb, pb, cb, gb consistent (GREEN open-accepted). Council decided to close. Action: JC to close ...
|JC
|JC to close [DONE].
|
|-
|[https://sourceforge.net/p/tei/bugs/525/ BUG 525] citedRange and biblScope should share att class (GREEN open). SB admitted to sloth. Action: SB to co...
|MH, JC, KH
|MH to check Allura settings to make sure that the owners of both bugs and feature requests receive email notifications. [JC and KH looked into this during a break and might have fixed it through another mechanism. MH to check with JC].
|
|-
|[https://sourceforge.net/p/tei/bugs/418/ BUG 418] Names and Dates chapter does not mention calendar (GREEN open). Action: JC will add the prose before...
|JC
|JC will add the prose before the next teleconference.
|
|}

===Actions for Kevin Hawkins===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|[https://sourceforge.net/p/tei/feature-requests/457/ FR 457] : KH: In the ticket I want to clarify what you use tagUsage for and what to put in a project-specifi...
|KH, LB, JC
|KH, LB, and JC will review and make a recommendation to Council before the next face-to-face.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/384/ FR 384] that once 384 is implemented, we’ll add a note on att.typed reminding people that this is meant for ...
|HC, KH
|HC will implement [DONE]. KH will add a comment to FR 384 [DONE].
|
|-
|[https://sourceforge.net/p/tei/feature-requests/468/ FR 468] : HC: precision expresses false precision that’s not real probability. It’s something more like cert...
|KH
|KH to add to the deprecation document the requirement to announce to the community that we plan to deprecate something and to get in touch if you object.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/383/ FR 383] where to put idno within biblStruct? (AMBER open) This is one of three tickets where KH could not fi...
|KH, SB
|KH will create a new ticket pointing to this and the other two tickets with deprecation problems (as listed on the wiki) saying we need a way to deprecate members of content model and reassign to SB to solve the three tickets using a Schematron warning, and to add @validUntil on constraintSpec.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/482/ FR 482] The term strikes back - terminology chapter (AMBER open). The ISO is working on a standard for termi...
|LB, KH, SB
|LB, KH and SB to articulate a more generic policy for TEI on the integration of external standards and will generate a one-page proposal for this policy. This should be provided to Council ahead of the next teleconference. In addition, LB, KH, and SB will check with Laurent that he wants TBX incorporated into the Guidelines as is or kept in sync in the future and what he thinks about melding into the rest of the TEI Guidelines (in language, approach, element naming conventions) or keeping it self-contained.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/294/ FR 294] altIdentifier is deprecated within msPart (AMBER open). Action: KH to change to Green and add to the...
|KH
|KH to change to Green and add to the ticket about deprecation using Schematron along with 383, if not already done.
|
|-
|[https://sourceforge.net/p/tei/bugs/528/ BUG 528] consistency in "the Guidelines" vs. "these Guidelines" (AMBER open). This should be green. Action: K...
|KH
|KH to do this.
|
|-
|[https://sourceforge.net/p/tei/bugs/548/ BUG 548] use of modal verbs in Guidelines (AMBER pending-later). Already assigned to KH. RW agreed to help. I...
|KH, RW, LB
|KH and RW to create a new, detailed ticket with all questionable cases. In the meantime, LB will fix the edits that KH made at r12525.
|
|-
|[https://sourceforge.net/p/tei/bugs/216/ BUG 216] half title pages in TEI Tite (AMBER open-postponed). KH has to finish comparing TEI-Tite with the Ap...
|KH
|KH to resolve Tite problems and report regularly to Council on progress.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/280/ FR 280] clarification of colloc (GREEN pending-accepted). #1 is already done. #2: Breakout group agreed that...
|KH
|KH to remove @type from both examples, etc.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/482/ FR 482] Earlier we decided:Action: LB, KH and SB to articulate a more generic policy for TEI on the integrat...
|LB, KH, SB
|LB, KH and SB to articulate a more generic policy for TEI on the integration of external standards and will generate a one-page proposal for this policy. This should be provided to Council ahead of the next teleconference. In addition, LB, KH, and SB will check with Laurent that he wants TBX incorporated into the Guidelines as is or kept in sync in the future and what he thinks about melding into the rest of the TEI Guidelines (in language, approach, element naming conventions) or keeping it self-contained.
|
|-
|[https://sourceforge.net/p/tei/bugs/525/ BUG 525] citedRange and biblScope should share att class (GREEN open). SB admitted to sloth. Action: SB to co...
|MH, JC, KH
|MH to check Allura settings to make sure that the owners of both bugs and feature requests receive email notifications. [JC and KH looked into this during a break and might have fixed it through another mechanism. MH to check with JC].
|
|}

===Actions for Martin Holmes===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|[https://sourceforge.net/p/tei/feature-requests/453/ FR 453] a place for metadata that you can't fit into existing header elements AMBER open Discussion talks mo...
|MH, PS, LB
|MH will offer DC examples and PS will offer MARC examples. LB will pull them together into some text to be inserted into the Guidelines. Given this, Council will reconsider the feature request and whether to create the wrapper element.
|Examples provided 2013-11-20
|-
|[https://sourceforge.net/p/tei/feature-requests/471/ FR 471] extend the possible usages of argument (AMBER open). (If the intended use case is encoder-supplied a...
|LB, MH
|
|
|-
|[https://sourceforge.net/p/tei/feature-requests/472/ FR 472] docDate in dateline ? EM: dateline does not allow docDate, but byline allows docAuthor. This is inco...
|MH
|MH to add docDate to dateline, and clarify with usage notes.
|Done 2013-11
|-
|[https://sourceforge.net/p/tei/feature-requests/443/ FR 443] @resp should be a member of att.global AMBER open. JC and SR: Global attributes should really not be...
|MH, LB
|MH and LB to agree on clarification to Guidelines to say that @resp means different things: responsibility for markup and content except when the element in question is a transcriptional element, in which case the content of the element is marked as coming from the source.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/303/ FR 303] check the apache logs for frequent 404s (AMBER open). Action: JC to ask DS to make the TEI-C webserv...
|JC, MH
|JC to ask DS to make the TEI-C webserver logs available somewhere we can see them; then action on MH to write script to generate lists of bad links of various types. JC also to check google analytics/Webmaster tools. Deadline to report back by next conference call.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/470/ FR 470] att.measurement and att.dimensions overlap (AMBER open). We are not really sure why all of these att...
|MH
|MH to move @commodity into its own class, and move measure and measureGrp to att.dimensions. Ticket to GREEN, assign to MH. [Subsequent study suggests to MH that this may be more complicated than it seems, and may have to wait on our having the ability to override valLists in attributes from attribute classes at the element level.]
|
|-
|[http://wiki.tei-c.org/index.php/Council_agenda_2013-11#More_Details_on_Agenda_topics bottom of wiki agenda page] ) SR: Why are we proposing using alpha and beta? MH: Because we were proposing asking the community ...
|MH, SR
|Assign MH to update the release documentation re alpha and beta, and investigate how we might add the SVN last changed date and the rev number to the bottom of pages.
|Latter bit done by SR 2013-11-14. Documentation in TCW22 updated by MH 2013-11-14.
|-
|i18n: take forward updating translations

|MH
|MH to get contact info on original groups and activate if possible, probably starting with French and Italian
|
|-
|[https://sourceforge.net/p/tei/feature-requests/405/ FR 405] Wrong schema generated (AMBER pending-accepted). This is due to a bug in the current version in Roma...
|MH
|MH to see if it has been fixed, and if so, close the ticket.
|Done 2013-11
|-
|[http://wiki.tei-c.org/index.php/Text_Directionality_Draft first draft of new Guidelines sections] and questions [MH] MH summarized the genesis of this text from Providence. He noted that not only th...
|MH, LB
|Entire Council to (re)read MH’s draft before next face-to-face meeting. Once we’ve done that and agreed, someone will rewrite chapter 5 (WD) to include MH’s draft and the current section 10.6.6. LB volunteered.
|
|-
|[https://sourceforge.net/p/tei/bugs/578/ BUG 578] partial and recursive segmentation of s-units (AMBER open). [The Guidelines text is clear enough. Th...
|MH
|MH will revise content model to match the prose.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/298/ BUG 298] att.editLike should not bring att.dimensions & att.ranging (AMBER open-accepted). [MH to ask Gabriel...
|MH
|MH to ask Gabby to implement.
|Emailed GB 2013-11-21
|-
|[https://sourceforge.net/p/tei/feature-requests/212/ FR 212] Generic dating class (AMBER pending-accepted). Gabby claimed in 2011 that it’s done except needs som...
|HC, MH
|HC to investigate whether it’s actually been done. MH offered examples if needed.
|
|-
|[https://sourceforge.net/p/tei/bugs/568/ BUG 568] "How to edit the Guidelines" and chapter organization (AMBER open). SR: What MH found looks distinct...
|MH
|MH to replace references to entity references with explanation of XIncludes in “How to edit the Guidelines”.
|Done 2013-11
|-
|[https://sourceforge.net/p/tei/bugs/506/ BUG 506] Meaning of @corresp rather in dispute (AMBER open). Working group triage: needs to be discussed: Is ...
|MH
|MH to create an example and run it by tei-council before adding to the Guidelines.
|
|-
|[https://sourceforge.net/p/tei/bugs/582/ BUG 582] Need for consistency in terminology relating to TEI conformance (AMBER open). Working group: Agreed ...
|MH
|MH to deal with the ticket narrowly, using a hyphen and lowercase but leaving both “conformant” and “conformable”.
|Done 2013-11-20
|-
|[https://sourceforge.net/p/tei/bugs/460/ BUG 460] list/@type="unordered" is not recommended, but used often (AMBER open). Working group: This bug has...
|MH
|MH to follow the last comment on ticket to figure out our current situation.
|
|-
|[https://sourceforge.net/p/tei/bugs/581/ BUG 581] `attRef` needs better documentation (AMBER open). Action: SR to implement either removal of attRef, ...
|SR, MH
|SR to implement either removal of attRef, MH to adjust documentation.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/432/ FR 432] Change regex flavor on @matchPattern (GREEN open). Agreed, XPath. Action: MH Write to TEI-L list, if...
|MH
|MH Write to TEI-L list, if no negative feedback, change.
|Done 2013-11-21 rev 12660
|-
|[https://sourceforge.net/p/tei/bugs/312/ BUG 312] i18n revision due (GREEN open). Action: MH, when he completes action on related ticket (perhaps afte...
|MH
|MH, when he completes action on related ticket (perhaps after moving notes from minutes into tickets), to update this ticket.
|
|-
|[https://sourceforge.net/p/tei/bugs/442/ BUG 442] update ODD documentation on www.tei-c.org and in Guidelines (GREEN open). Action: MH to finish it....
|MH
|MH to finish it.
|
|-
|[https://sourceforge.net/p/tei/bugs/441/ BUG 441] fDecl doesn't allow att.datcat yet (GREEN open-accepted). Action: MH to prod Piotr....
|MH
|MH to prod Piotr.
|Piotr prodded 2013-11-21
|-
|[https://sourceforge.net/p/tei/bugs/525/ BUG 525] citedRange and biblScope should share att class (GREEN open). SB admitted to sloth. Action: SB to co...
|MH, JC, KH
|MH to check Allura settings to make sure that the owners of both bugs and feature requests receive email notifications. [JC and KH looked into this during a break and might have fixed it through another mechanism. MH to check with JC].
|
|}

===Actions for Elli Mylonas===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|Ideas on how to run an experimental TEI Hackathon [SR]

|JC, HC, SR, EM
|JC to approach the DH 2014 committee and find out how they would prefer us to do it, and whether it’s a good idea; and tell the Board that HC, SR and EM are prepared to be involved in organizing this along with one or more Board members.
|
|-
|Ideas on how to run an experimental TEI Hackathon [SR]

|EM
|EM to make sure this happens.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/300/ FR 300] Move witStart et al. to model.milestoneLike (AMBER pending). Action: EM to change to red and assigne...
|EM
|EM to change to red and assigned to EM to chase up or otherwise close ticket.
|
|-
|[https://sourceforge.net/p/tei/bugs/594/ BUG 594] TEI-C website menu points to wrong index page for Guidelines (AMBER open). Fixed, will appear in nex...
|EM
|EM to create a ticket on the Chrome problem.
|
|-
|[https://sourceforge.net/p/tei/bugs/589/ BUG 589] add respons and space to att.responsibility (AMBER open). Working group triage: Is it ok to add have...
|EM
|EM will get rid of locally assigned @resp by adding to att.responsibility (thereby getting @cert as well). Will change to GREEN.
|
|-
|[https://sourceforge.net/p/tei/bugs/563/ BUG 563] inconsistent encoding of citations to sources of examples (AMBER open). Working group recommends ass...
|BB, EM, PS
|BB, EM, and PS to work on the ticket by mid-February 2014.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/389/ FR 389] clarify definition of @from on locus and biblScope (GREEN open). EM admits to sloth and will do so. ...
|EM
|EM to do before next teleconference.
|
|-
|[http://wiki.tei-c.org/index.php/TEI_Cheatsheets Cheatsheets: Short best/recommended practice documents] EM: Not cheatsheets - negative implication. RW: Quick Start. HC: Quick Reference; SB: “Guidelettes” ...
|EM
|EM to ask MB to clarify what she wants from Council with regard to helping cheatsheets.
|
|}

===Actions for Sebastian Rahtz===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|[http://tei.oucs.ox.ac.uk/EEBO/ http://tei.oucs.ox.ac.uk/EEBO/] for summary of problem, and links to tickets) SR: EEBO-TCP is a gigantic resource that claims to be ...
|SR
|SR will implement the schema change of adding @place to stage and will document and provide an example.
|adding @place. example to do
|-
|[https://sourceforge.net/p/tei/feature-requests/479/ FR 479] Adding the @place attribute to head and seg AMBER open JC noted that head is not meta-textual or in ...
|SR
|SR to take the ticket, and get more examples from the submitter
|DONE
|-
|[https://sourceforge.net/p/tei/feature-requests/445/ FR 445] Conversion of ODD to HTML: Examples should be aware of element renaming closed-fixed, implemented by...
|SR
|SR to add gi and att renaming to complete the ticket.
| COMPLETED FOR gi. Not possible for att.
|-
|[https://sourceforge.net/p/tei/feature-requests/442/ FR 442] Allow foreign to contain q (AMBER open). The group felt this should be rejected. Action:SR to close ...
|SR
|SR to close ticket because it’s rejected
|DONE
|-
|[https://sourceforge.net/p/tei/feature-requests/433/ FR 433] loosen content model of salute (AMBER open). SR: Underlying this was a desire for symmetry between s...
|SR
|SR will carry this out
|DONE
|-
|[https://sourceforge.net/p/tei/feature-requests/477/ FR 477] lines of poetry inside trailer (AMBER open). The request is for symmetry between head and trailer. T...
|SR
|SR to find a good way to achieve this, since what was done before with head was rather strange.
|DONE. Have copied what was done with head
|-
|[https://sourceforge.net/p/tei/feature-requests/383/ FR 383] where to put idno within biblStruct? (AMBER open) This is one of three tickets where KH could not fi...
|SR
|SR to check how @validUntil makes the build fail when out of date, and if necessary update this mechanism so it can handle @validUntil on constraintSpec. Ticket 383 will wait on all this, along with the two other tickets.
|DONE. It applies to tei:*[@validUntil], so should just work.] .
|-
|[http://wiki.tei-c.org/index.php/Council_agenda_2013-11#More_Details_on_Agenda_topics bottom of wiki agenda page] ) SR: Why are we proposing using alpha and beta? MH: Because we were proposing asking the community ...
|MH, SR
|Assign MH to update the release documentation re alpha and beta, and investigate how we might add the SVN last changed date and the rev number to the bottom of pages.
|Latter bit done by SR 2013-11-14. Documentation in TCW22 updated by MH 2013-11-14.]
|-
|Ideas on how to run an experimental TEI Hackathon [SR]
|JC, HC, SR, EM
|JC to approach the DH 2014 committee and find out how they would prefer us to do it, and whether it’s a good idea; and tell the Board that HC, SR and EM are prepared to be involved in organizing this along with one or more Board members.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/345/ FR 345] members of model.respLike should be members of att.declarable (AMBER open-later). Breakout group ins...
|SR
|SR to make the ticket Green and go ahead and implement it, including some documentation/examples.
|DONE
|-
|[https://sourceforge.net/p/tei/bugs/302/ BUG 302] version ignores @source (AMBER open). This is a Roma issue. Recommend marking as closed won’t fix be...
|SR
|SR to try reproducing this and set as closed-won’t fix.
|DONE
|-
|[https://sourceforge.net/p/tei/bugs/583/ BUG 583] Adding new attribute fails in Roma schema generation (AMBER open). Same as 302. Action: SR wil set a...
|SR
|SR wil set as closed-won’t fix and check that it has the Roma tag.
|DONE
|-
|[https://sourceforge.net/p/tei/bugs/434/ BUG 434] issues with ePub conversion (2/3) (AMBER open). Any issue not dealing with ODD processing should be ...
|SR
|SR will ask poster kindly to post there (explaining why) and close this issue.
|DONE
|-
|[https://sourceforge.net/p/tei/bugs/581/ BUG 581] `attRef` needs better documentation (AMBER open). Action: SR to implement either removal of attRef, ...
|SR, MH
|SR to implement either removal of attRef, MH to adjust documentation.
|FIxed attRef. thinking about classRef
|-
|[https://sourceforge.net/p/tei/feature-requests/467/ FR 467] Make @name optional on tei:relation (GREEN open). Action: SR has already done this....
|SR
|SR to action
|DOne
|-
|[https://sourceforge.net/p/tei/feature-requests/478/ FR 478] loosening content and model of `signed` (GREEN open). Agree that is is green. Though would model.div...
|SR
|SR to implement signed at top as well as bottom
|DONE
|}

===Actions for Paul Schaffner===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|[https://sourceforge.net/p/tei/feature-requests/453/ FR 453] a place for metadata that you can't fit into existing header elements AMBER open Discussion talks mo...
|MH, PS, LB
|MH will offer DC examples and PS will offer MARC examples. LB will pull them together into some text to be inserted into the Guidelines. Given this, Council will reconsider the feature request and whether to create the wrapper element.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/360/ FR 360] New attribute @keepHyphen. Ticket open, ticket GREEN, it’s rejected throughout the comments....
|PS
|PS to provide an example of the mechanism recommended to handle the use-case.
|
|-
|[https://sourceforge.net/p/tei/bugs/563/ BUG 563] inconsistent encoding of citations to sources of examples (AMBER open). Working group recommends ass...
|BB, EM, PS
|BB, EM, and PS to work on the ticket by mid-February 2014.
|
|-
|[https://sourceforge.net/p/tei/bugs/558/ BUG 558] name/orgName (AMBER open). Action: RW to ask PS where he is on this; change ticket status to GREEN....
|RW, PS
|RW to ask PS where he is on this; change ticket status to GREEN.
|
|}

===Actions for Torsten Schassan===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|

|TS
|TS to come up with a more detailed problem description and what the WG should attempt to solve by 2014-01-01.
|
|}

===Actions for Rebecca Welzenbach===
{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|[https://sourceforge.net/p/tei/feature-requests/384/ FR 384] : In April RW made a spreadsheet showing which elements she recommends moving into att.typed. And in...
|SB, RW
|SB and RW will review the list again.
|
|-
|Attributes without examples

|BB, RW
|BB and RW to turn into bug reports those attributes that are without examples that are high priority or need new/updated definitions.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/377/ FR 377] retaining punctuation marks in the text of a TEI document (AMBER open-accepted). RW says she has add...
|RW
|RW to finish the work and ask for help if necessary.
|
|-
|[https://sourceforge.net/p/tei/bugs/548/ BUG 548] use of modal verbs in Guidelines (AMBER pending-later). Already assigned to KH. RW agreed to help. I...
|KH, RW, LB
|KH and RW to create a new, detailed ticket with all questionable cases. In the meantime, LB will fix the edits that KH made at r12525.
|
|-
|[https://sourceforge.net/p/tei/bugs/558/ BUG 558] name/orgName (AMBER open). Action: RW to ask PS where he is on this; change ticket status to GREEN....
|RW, PS
|RW to ask PS where he is on this; change ticket status to GREEN.
|
|-
|[https://sourceforge.net/p/tei/bugs/401/ BUG 401] Most attributes lack good examples (GREEN open-accepted). This was previously discussed. Action: RW ...
|RW
|RW to follow up.
|
|}

[[Category:Council]]

Oxford2013-Actions

2013-11-21T14:17:03Z

Rahtz: /* Council Actions from November 2013 Oxford Meeting */

==Council Actions from November 2013 Oxford Meeting==

A list of actions, those responsible, and what has been done about them from Oxford 2013 face to face meeting of TEI Technical Council

{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|[http://tei.oucs.ox.ac.uk/EEBO/ http://tei.oucs.ox.ac.uk/EEBO/] for summary of problem, and links to tickets) SR: EEBO-TCP is a gigantic resource that claims to be ...
|SR
|SR will implement the schema change of adding @place to stage and will document and provide an example.
|@place added to <stage>
|-
|
|HC
|HC to report on XPointer resolver and whether we should progress it.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/384/ FR 384] : In April RW made a spreadsheet showing which elements she recommends moving into att.typed. And in...
|SB, RW
|SB and RW will review the list again.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/457/ FR 457] : KH: In the ticket I want to clarify what you use tagUsage for and what to put in a project-specifi...
|KH, LB, JC
|KH, LB, and JC will review and make a recommendation to Council before the next face-to-face.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/459/ FR 459] : This is just waiting for implementation....
|SB
|SB will implement by end of January 2014.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/465/ FR 465] : Gabby and HC seem to agree on it, and the example looks sensible. LB’s comment could be raised as ...
|HC
|HC will implement before end of January 2014.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/453/ FR 453] a place for metadata that you can't fit into existing header elements AMBER open Discussion talks mo...
|MH, PS, LB
|MH will offer DC examples and PS will offer MARC examples. LB will pull them together into some text to be inserted into the Guidelines. Given this, Council will reconsider the feature request and whether to create the wrapper element.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/384/ FR 384] that once 384 is implemented, we’ll add a note on att.typed reminding people that this is meant for ...
|HC, KH
|HC will implement [DONE]. KH will add a comment to FR 384 [DONE].
|
|-
|[https://sourceforge.net/p/tei/feature-requests/479/ FR 479] Adding the @place attribute to head and seg AMBER open JC noted that head is not meta-textual or in ...
|SR
|SR to take the ticket, and get more examples from the submitter .
|started
|-
|[https://sourceforge.net/p/tei/feature-requests/476/ FR 476] use of stage inside poetry, and using placement attribute (AMBER open). (Council agreed to @place; s...
|JC
|JC to close ticket FR 476 noting it has been resolved.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/481/ FR 481] check that all sibling att.translatable elements have @versionDate (AMBER open). (Agreed that siblin...
|SB
|SB to check whether this is implemented, and if not, get it implemented then close the ticket.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/462/ FR 462] idno@type='uri' for Linked Data AMBER open (We agreed. @type=”URI” alongside @type=”URL”) EM: The su...
|HC
|HC to implement this and close the ticket FR 462.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/471/ FR 471] extend the possible usages of argument (AMBER open). (If the intended use case is encoder-supplied a...
|LB, MH
|
|
|-
|[https://sourceforge.net/p/tei/feature-requests/472/ FR 472] docDate in dateline ? EM: dateline does not allow docDate, but byline allows docAuthor. This is inco...
|MH
|MH to add docDate to dateline, and clarify with usage notes [Done].
|
|-
|[https://sourceforge.net/p/tei/feature-requests/360/ FR 360] New attribute @keepHyphen. Ticket open, ticket GREEN, it’s rejected throughout the comments....
|PS
|PS to provide an example of the mechanism recommended to handle the use-case.
|
|-
|
|LB
|LB to add the new elements and the documentation ahead of the next release; documentation need only be at the element level, along with some brief introduction in the Guidelines, to be expanded to a full section later.
|
|-
|[https://docs.google.com/document/d/1766WTJV2xcfANh8HRZW5m520yrC1nCzQJzUgKpwiylI/edit TEI Roma Replacement Specification] JC: The existing Roma is dated and flawed, as we all know. Many tickets have come up which we cannot...
|JC
|ALL Council to go through the proposal again and discuss it, remembering to look at the comments, and further refine it. JC to make sure it’s tidied up. Deadline: next teleconference.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/445/ FR 445] Conversion of ODD to HTML: Examples should be aware of element renaming closed-fixed, implemented by...
|SR
|SR to add gi and att renaming to complete the ticket.
|DONE for gi. Not possible for att.
|-
|[https://sourceforge.net/p/tei/feature-requests/443/ FR 443] @resp should be a member of att.global AMBER open. JC and SR: Global attributes should really not be...
|MH, LB
|MH and LB to agree on clarification to Guidelines to say that @resp means different things: responsibility for markup and content except when the element in question is a transcriptional element, in which case the content of the element is marked as coming from the source.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/468/ FR 468] : HC: precision expresses false precision that’s not real probability. It’s something more like cert...
|KH
|KH to add to the deprecation document the requirement to announce to the community that we plan to deprecate something and to get in touch if you object.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/468/ FR 468] : HC: precision expresses false precision that’s not real probability. It’s something more like cert...
|HC
|HC to email TEI-L.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/468/ FR 468] : HC: precision expresses false precision that’s not real probability. It’s something more like cert...
|SB
|
|
|-
|[https://sourceforge.net/p/tei/feature-requests/303/ FR 303] check the apache logs for frequent 404s (AMBER open). Action: JC to ask DS to make the TEI-C webserv...
|JC, MH
|JC to ask DS to make the TEI-C webserver logs available somewhere we can see them; then action on MH to write script to generate lists of bad links of various types. JC also to check google analytics/Webmaster tools. Deadline to report back by next conference call.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/305/ FR 305] Updating info on projects page (AMBER open). Project pages go out of date. There is a way to submit ...
|JC
|JC to ask DS to make that correction info available on each project page, along with its last-updated date if possible (and the latter should also show up on the bullet-point list).
|
|-
|[https://sourceforge.net/p/tei/feature-requests/466/ FR 466] Make it possible to add SIG labels to tickets (AMBER open). Action: JC as SIG Coordinator to tell th...
|JC
|JC as SIG Coordinator to tell the SIGs that if they wish, we can make their SIG convener a developer on SF and make it possible to assign SIG labels to tickets. Deadline: next teleconference.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/470/ FR 470] att.measurement and att.dimensions overlap (AMBER open). We are not really sure why all of these att...
|MH
|MH to move @commodity into its own class, and move measure and measureGrp to att.dimensions. Ticket to GREEN, assign to MH. [Subsequent study suggests to MH that this may be more complicated than it seems, and may have to wait on our having the ability to override valLists in attributes from attribute classes at the element level.]
|
|-
|[https://sourceforge.net/p/tei/feature-requests/442/ FR 442] Allow foreign to contain q (AMBER open). The group felt this should be rejected. Action:SR to close ...
|SR
|SR to close ticket because it’s rejected
|DONE
|-
|[https://sourceforge.net/p/tei/feature-requests/433/ FR 433] loosen content model of salute (AMBER open). SR: Underlying this was a desire for symmetry between s...
|SR
|SR will carry this out
|DONE
|-
|[https://sourceforge.net/p/tei/feature-requests/477/ FR 477] lines of poetry inside trailer (AMBER open). The request is for symmetry between head and trailer. T...
|SR
|SR to find a good way to achieve this, since what was done before with head was rather strange.
|DONE have copied what was done with head.
|-
|[https://sourceforge.net/p/tei/feature-requests/383/ FR 383] where to put idno within biblStruct? (AMBER open) This is one of three tickets where KH could not fi...
|KH, SB
|KH will create a new ticket pointing to this and the other two tickets with deprecation problems (as listed on the wiki) saying we need a way to deprecate members of content model and reassign to SB to solve the three tickets using a Schematron warning, and to add @validUntil on constraintSpec.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/383/ FR 383] where to put idno within biblStruct? (AMBER open) This is one of three tickets where KH could not fi...
|SR
|SR to check how @validUntil makes the build fail when out of date, and if necessary update this mechanism so it can handle @validUntil on constraintSpec
|DONE. It applies to tei:*[@validUntil], so should just work. . (Ticket 383 will wait on all this, along with the two other tickets.)
|-
|[https://sourceforge.net/p/tei/feature-requests/366/ FR 366] rationalize content models of org and place (etc) (AMBER open). Group thinks a small group of people...
|JC, LB, SB
|JC to make ticket red, should stay with JC, and he should initiate the process, working with LB and SB.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/458/ FR 458] Make listBibl and model.biblLike member of model.personPart (AMBER open). Lou has already done items...
|LB
|close the ticket.
|DONE
|-
|[http://wiki.tei-c.org/index.php/Council_agenda_2013-11#More_Details_on_Agenda_topics bottom of wiki agenda page] ) SR: Why are we proposing using alpha and beta? MH: Because we were proposing asking the community ...
|MH, SR
|Assign MH to update the release documentation re alpha and beta, and investigate how we might add the SVN last changed date and the rev number to the bottom of pages.
|Latter bit done by SR 2013-11-14. Documentation in TCW22 updated by MH 2013-11-14.
|-
|
|JC, HC, SR, EM
|JC to approach the DH 2014 committee and find out how they would prefer us to do it, and whether it’s a good idea; and tell the Board that HC, SR and EM are prepared to be involved in organizing this along with one or more Board members.
|
|-
|
|EM
|EM to make sure this happens.
|
|-
|
|MH
|MH to get contact info on original groups and activate if possible, probably starting with French and Italian
|
|-
|
|LB
|LB to testdrive the spreadsheet.
|Spreadsheet sent to FC 2013-11-18
|-
|
|BB, RW
|BB and RW to turn into bug reports those attributes that are without examples that are high priority or need new/updated definitions.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/482/ FR 482] The term strikes back - terminology chapter (AMBER open). The ISO is working on a standard for termi...
|LB, KH, SB
|LB, KH and SB to articulate a more generic policy for TEI on the integration of external standards and will generate a one-page proposal for this policy. This should be provided to Council ahead of the next teleconference. In addition, LB, KH, and SB will check with Laurent that he wants TBX incorporated into the Guidelines as is or kept in sync in the future and what he thinks about melding into the rest of the TEI Guidelines (in language, approach, element naming conventions) or keeping it self-contained.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/405/ FR 405] Wrong schema generated (AMBER pending-accepted). This is due to a bug in the current version in Roma...
|MH
|MH to see if it has been fixed, and if so, close the ticket [DONE].
|
|-
|[https://sourceforge.net/p/tei/feature-requests/294/ FR 294] altIdentifier is deprecated within msPart (AMBER open). Action: KH to change to Green and add to the...
|KH
|KH to change to Green and add to the ticket about deprecation using Schematron along with 383, if not already done.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/264/ FR 264] altIdentifier in msPart (AMBER pending-accepted). Action: JC to change to Green and assign to himsel...
|JC
|JC to change to Green and assign to himself, then nudge Torsten for an example of an altIdentifier within an msPart.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/300/ FR 300] Move witStart et al. to model.milestoneLike (AMBER pending). Action: EM to change to red and assigne...
|EM
|EM to change to red and assigned to EM to chase up or otherwise close ticket.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/377/ FR 377] retaining punctuation marks in the text of a TEI document (AMBER open-accepted). RW says she has add...
|RW
|RW to finish the work and ask for help if necessary.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/345/ FR 345] members of model.respLike should be members of att.declarable (AMBER open-later). Breakout group ins...
|SR
|SR to make the ticket Green and go ahead and implement it, including some documentation/examples.
|DONE
|-
|[https://sourceforge.net/p/tei/feature-requests/480/ FR 480] Adding the @hand attribute to all (or most) text-containing elements (AMBER open). Breakout group wa...
|LB
|LB to respond to the ticket FR 480.
|
|-
|[https://sourceforge.net/p/tei/bugs/276/ BUG 276] internationalisation links (AMBER open). Language links at bottom of a page should take you to same ...
|JC, SB
|JC to make Green and allocate to SB.
|
|-
|[https://sourceforge.net/p/tei/bugs/594/ BUG 594] TEI-C website menu points to wrong index page for Guidelines (AMBER open). Fixed, will appear in nex...
|EM
|EM to create a ticket on the Chrome problem.
|
|-
|[https://sourceforge.net/p/tei/bugs/619/ BUG 619] tei_allPlus.rng: conflicting ID-types for attribute "id" of element "partialdiff" from namespace "ht...
|SB
|SB to double-check whether able to reproduce and report back on ticket if able to.
|
|-
|[http://wiki.tei-c.org/index.php/Text_Directionality_Draft first draft of new Guidelines sections] and questions [MH] MH summarized the genesis of this text from Providence. He noted that not only th...
|MH, LB
|Entire Council to (re)read MH’s draft before next face-to-face meeting. Once we’ve done that and agreed, someone will rewrite chapter 5 (WD) to include MH’s draft and the current section 10.6.6. LB volunteered.
|
|-
|[https://sourceforge.net/p/tei/bugs/288/ BUG 288] deprecate use of gram except as a child of gramGrp (AMBER open-accepted). [This is pending creation ...
|SB
|SB to create the new ticket and write the Schematron for this particular deprecation.
|
|-
|[https://sourceforge.net/p/tei/bugs/515/ BUG 515] Bad example of feature/@fVal (AMBER open). [Change this to RED as it’s not clear what needs changin...
|JC
|JC to check that’s been changed to RED [DONE].
|
|-
|[https://sourceforge.net/p/tei/bugs/578/ BUG 578] partial and recursive segmentation of s-units (AMBER open). [The Guidelines text is clear enough. Th...
|MH
|MH will revise content model to match the prose.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/298/ BUG 298] att.editLike should not bring att.dimensions & att.ranging (AMBER open-accepted). [MH to ask Gabriel...
|MH
|MH to ask Gabby to implement.
|
|-
|[https://sourceforge.net/p/tei/bugs/302/ BUG 302] version ignores @source (AMBER open). This is a Roma issue. Recommend marking as closed won’t fix be...
|SR
|SR to try reproducing this and set as closed-won’t fix.
|CLOSED
|-
|[https://sourceforge.net/p/tei/bugs/583/ BUG 583] Adding new attribute fails in Roma schema generation (AMBER open). Same as 302. Action: SR wil set a...
|SR
|SR wil set as closed-won’t fix and check that it has the Roma tag.
|DONE
|-
|[https://sourceforge.net/p/tei/bugs/434/ BUG 434] issues with ePub conversion (2/3) (AMBER open). Any issue not dealing with ODD processing should be ...
|SR
|SR will ask poster kindly to post there (explaining why) and close this issue.
|DONE
|-
|[https://sourceforge.net/p/tei/feature-requests/212/ FR 212] Generic dating class (AMBER pending-accepted). Gabby claimed in 2011 that it’s done except needs som...
|HC, MH
|HC to investigate whether it’s actually been done. MH offered examples if needed.
|
|-
|[https://sourceforge.net/p/tei/bugs/528/ BUG 528] consistency in "the Guidelines" vs. "these Guidelines" (AMBER open). This should be green. Action: K...
|KH
|KH to do this.
|
|-
|[https://sourceforge.net/p/tei/bugs/548/ BUG 548] use of modal verbs in Guidelines (AMBER pending-later). Already assigned to KH. RW agreed to help. I...
|KH, RW, LB
|KH and RW to create a new, detailed ticket with all questionable cases. In the meantime, LB will fix the edits that KH made at r12525.
|
|-
|[https://sourceforge.net/p/tei/bugs/568/ BUG 568] "How to edit the Guidelines" and chapter organization (AMBER open). SR: What MH found looks distinct...
|MH
|MH to replace references to entity references with explanation of XIncludes in “How to edit the Guidelines” [DONE].
|
|-
|[https://sourceforge.net/p/tei/bugs/585/ BUG 585] Precision element missing att.ranging class (AMBER open). Working group closed. Action: EB to ask Ga...
|
|EB to ask Gabby to open a new one about clarifying this element and relevant parts of the chapter on dating, to explain and exemplify the use of these attributes.
|
|-
|[https://sourceforge.net/p/tei/bugs/589/ BUG 589] add respons and space to att.responsibility (AMBER open). Working group triage: Is it ok to add have...
|EM
|EM will get rid of locally assigned @resp by adding to att.responsibility (thereby getting @cert as well). Will change to GREEN.
|
|-
|[https://sourceforge.net/p/tei/bugs/506/ BUG 506] Meaning of @corresp rather in dispute (AMBER open). Working group triage: needs to be discussed: Is ...
|MH
|MH to create an example and run it by tei-council before adding to the Guidelines.
|
|-
|[https://sourceforge.net/p/tei/bugs/563/ BUG 563] inconsistent encoding of citations to sources of examples (AMBER open). Working group recommends ass...
|BB, EM, PS
|BB, EM, and PS to work on the ticket by mid-February 2014.
|
|-
|[https://sourceforge.net/p/tei/bugs/582/ BUG 582] Need for consistency in terminology relating to TEI conformance (AMBER open). Working group: Agreed ...
|MH
|MH to deal with the ticket narrowly, using a hyphen and lowercase but leaving both “conformant” and “conformable” [DONE].
|
|-
|[https://sourceforge.net/p/tei/bugs/582/ BUG 582] Need for consistency in terminology relating to TEI conformance (AMBER open). Working group: Agreed ...
|JC
|JC will create a ticket to reconsider the discussion of “conformable” and “conformant” in the Guidelines.
|
|-
|[https://sourceforge.net/p/tei/bugs/460/ BUG 460] list/@type="unordered" is not recommended, but used often (AMBER open). Working group: This bug has...
|MH
|MH to follow the last comment on ticket to figure out our current situation.
|
|-
|[https://sourceforge.net/p/tei/bugs/468/ BUG 468] Order of elements in publicationStmt (AMBER open-accepted). Group discussion: SB: Despite Lou’s comm...
|SB, LB
|SB will do the content model and LB will do the prose. They’ll work out the specifics.
|
|-
|
|
|TS to come up with a more detailed problem description and what the WG should attempt to solve by 2014-01-01.
|
|-
|[https://sourceforge.net/p/tei/bugs/581/ BUG 581] `attRef` needs better documentation (AMBER open). Action: SR to implement either removal of attRef, ...
|SR, MH
|SR to implement either removal of attRef, MH to adjust documentation.
|Started. attRef cleared up. more thinking to do
|-
|[https://sourceforge.net/p/tei/bugs/405/ BUG 405] XPointer schemes may not nest, but see ch. 16 (AMBER open). Action: SB to fix documentation....
|SB
|SB to fix documentation.
|
|-
|[https://sourceforge.net/p/tei/bugs/601/ BUG 601] att.patternReplacement/@matchPattern should be XPath regex, not XML Schema (AMBER open). Action: JC ...
|JC
|JC to close as a dupe of FR 432.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/432/ FR 432] Change regex flavor on @matchPattern (GREEN open). Agreed, XPath. Action: MH Write to TEI-L list, if...
|MH
|MH Write to TEI-L list, if no negative feedback, change.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/469/ FR 469] add extent to att.dimensions (GREEN open). Agreed. Action: LB to provide an example in HD chapter (2...
|LB
|LB to provide an example in HD chapter (2.2.3) and close ticket.
|DONE
|-
|[https://sourceforge.net/p/tei/feature-requests/460/ FR 460] Use of geogFeat in transcription? (GREEN open). Ok. Action: JC to do it before next teleconference....
|JC
|JC to do it before next teleconference.
|
|-
|[https://sourceforge.net/p/tei/bugs/605/ BUG 605] clarifying add vs. supplied and del vs. surplus (AMBER open). Action: HC to emend the prose of the p...
|HC, LB
|HC to emend the prose of the paragraph beginning "The add element should not be used" to reference the surplus element also; LB points out that the specList can't be modified, because supplied/surplus aren't defined in Core.
|
|-
|[https://sourceforge.net/p/tei/bugs/609/ BUG 609] "lemma" used in a confusing way in CriticalApparatus.xml (AMBER open). Action: LB to remove the phra...
|LB
|LB to remove the phrase "on any one lemma" from the @varSeq description.
|DONE
|-
|[https://sourceforge.net/p/tei/bugs/610/ BUG 610] "lem" used in a confusing way in CriticalApparatus.xml (AMBER open). Action: BB to remove the last c...
|BB
|BB to remove the last clause of the sentence in question, beginning ", or to make clear".
|
|-
|[https://sourceforge.net/p/tei/bugs/558/ BUG 558] name/orgName (AMBER open). Action: RW to ask PS where he is on this; change ticket status to GREEN....
|RW, PS
|RW to ask PS where he is on this; change ticket status to GREEN.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/474/ FR 474] add an exemplum for @ref (GREEN open). Action: JC to poke JC; deadline by next teleconference....
|JC
|JC to poke JC; deadline by next teleconference.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/475/ FR 475] Stop using attributes to store space-delimited values (GREEN open). Nothing wrong with space-delimit...
|JC
|JC to Close as Closed-rejected.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/461/ FR 461] Two small improvements to `recording` (GREEN open). Action: LB to do this by next teleconference....
|LB
|LB to do this by next teleconference.
|DONE
|-
|[https://sourceforge.net/p/tei/feature-requests/467/ FR 467] Make @name optional on tei:relation (GREEN open). Action: SR has already done this....
|SR
|SR to do
|DONE
|-
|[https://sourceforge.net/p/tei/bugs/216/ BUG 216] half title pages in TEI Tite (AMBER open-postponed). KH has to finish comparing TEI-Tite with the Ap...
|KH
|KH to resolve Tite problems and report regularly to Council on progress.
|
|-
|[https://sourceforge.net/p/tei/bugs/216/ BUG 216] half title pages in TEI Tite (AMBER open-postponed). KH has to finish comparing TEI-Tite with the Ap...
|
|Council to ask for reports before each meeting.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/478/ FR 478] loosening content and model of `signed` (GREEN open). Agree that is is green. Though would model.div...
|SR
|SR to implement signed at top as well as bottom
|DONE
|-
|[https://sourceforge.net/p/tei/feature-requests/280/ FR 280] clarification of colloc (GREEN pending-accepted). #1 is already done. #2: Breakout group agreed that...
|KH
|KH to remove @type from both examples, etc.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/389/ FR 389] clarify definition of @from on locus and biblScope (GREEN open). EM admits to sloth and will do so. ...
|EM
|EM to do before next teleconference.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/401/ FR 401] extend and clarify use of particDesc and settingDesc (GREEN open). JC admits sloth and will implemen...
|JC
|JC to implement before next teleconference; Council decides it might be better to add these (model.
|
|-
|[http://wiki.tei-c.org/index.php/TEI_Cheatsheets Cheatsheets: Short best/recommended practice documents] EM: Not cheatsheets - negative implication. RW: Quick Start. HC: Quick Reference; SB: “Guidelettes” ...
|EM
|EM to ask MB to clarify what she wants from Council with regard to helping cheatsheets.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/482/ FR 482] Earlier we decided:Action: LB, KH and SB to articulate a more generic policy for TEI on the integrat...
|LB, KH, SB
|LB, KH and SB to articulate a more generic policy for TEI on the integration of external standards and will generate a one-page proposal for this policy. This should be provided to Council ahead of the next teleconference. In addition, LB, KH, and SB will check with Laurent that he wants TBX incorporated into the Guidelines as is or kept in sync in the future and what he thinks about melding into the rest of the TEI Guidelines (in language, approach, element naming conventions) or keeping it self-contained.
|
|-
|[http://sourceforge.net/p/tei/feature-requests/378/ FR 378] ; c.f. A Generic Formalism for Encoding Standoff annotations in TEI). Action: JC to ask Peter Stadle...
|JC, HC, SB
|JC to ask Peter Stadler if he’d like to attend as Council rep; otherwise any interested members of Council (HC,SB) are encouraged to attend virtually.
|
|-
|
|SB, LB
|SB and LB would like to (re?-)join the task force. Council advises them to keep in mind the work by the Ontology/MS SIGs, in particular Torsten Schassan, on an ‘object’ or ‘objectDesc’ element.
|
|-
|[https://sourceforge.net/p/tei/bugs/229/ BUG 229] Check desc of all xs:anyURI atts for in-doc restrictions (GREEN pending). We got rid of data.code al...
|JC
|JC to check prose discussion all xsd:anyURI attributes by next teleconference.
|
|-
|[https://sourceforge.net/p/tei/bugs/312/ BUG 312] i18n revision due (GREEN open). Action: MH, when he completes action on related ticket (perhaps afte...
|MH
|MH, when he completes action on related ticket (perhaps after moving notes from minutes into tickets), to update this ticket.
|
|-
|[https://sourceforge.net/p/tei/bugs/442/ BUG 442] update ODD documentation on www.tei-c.org and in Guidelines (GREEN open). Action: MH to finish it....
|MH
|MH to finish it.
|
|-
|[https://sourceforge.net/p/tei/bugs/336/ BUG 336] AdBlock blocks 'msad' ID (GREEN pending-later). Per last comment, time has passed and nothing else h...
|JC
|JC to close ticket.
|
|-
|[https://sourceforge.net/p/tei/bugs/587/ BUG 587] Guidelines version info on pages should link better (GREEN open). Action: JC to carry out his last c...
|JC
|JC to carry out his last comment on the ticket.
|
|-
|[https://sourceforge.net/p/tei/bugs/519/ BUG 519] Make lb, pb, cb, gb consistent (GREEN open-accepted). Council decided to close. Action: JC to close ...
|JC
|JC to close
|DONE
|-
|[https://sourceforge.net/p/tei/bugs/441/ BUG 441] fDecl doesn't allow att.datcat yet (GREEN open-accepted). Action: MH to prod Piotr....
|MH
|MH to prod Piotr.
|
|-
|[https://sourceforge.net/p/tei/bugs/525/ BUG 525] citedRange and biblScope should share att class (GREEN open). SB admitted to sloth. Action: SB to co...
|SB
|SB to complete.
|
|-
|[https://sourceforge.net/p/tei/bugs/525/ BUG 525] citedRange and biblScope should share att class (GREEN open). SB admitted to sloth. Action: SB to co...
|MH, JC, KH
|MH to check Allura settings to make sure that the owners of both bugs and feature requests receive email notifications. [JC and KH looked into this during a break and might have fixed it through another mechanism. MH to check with JC].
|
|-
|[https://sourceforge.net/p/tei/bugs/418/ BUG 418] Names and Dates chapter does not mention calendar (GREEN open). Action: JC will add the prose before...
|JC
|JC will add the prose before the next teleconference.
|
|-
|[https://sourceforge.net/p/tei/bugs/401/ BUG 401] Most attributes lack good examples (GREEN open-accepted). This was previously discussed. Action: RW ...
|RW
|RW to follow up.
|
|-
|[https://sourceforge.net/p/tei/bugs/387/ BUG 387] clarifying heading or title of a graphic (GREEN open). LB recently posted a comment approving of the...
|BB
|BB will implement the ticket.
|
|}
[[Category:Council]]

Oxford2013-Actions

2013-11-20T21:57:21Z

Rahtz: /* Council Actions from November 2013 Oxford Meeting */

==Council Actions from November 2013 Oxford Meeting==

A list of actions, those responsible, and what has been done about them from Oxford 2013 face to face meeting of TEI Technical Council

{|class="wikitable sortable"
|Ticket
|Who
|What
|Result
|-
|[http://tei.oucs.ox.ac.uk/EEBO/ http://tei.oucs.ox.ac.uk/EEBO/] for summary of problem, and links to tickets) SR: EEBO-TCP is a gigantic resource that claims to be ...
|SR
|SR will implement the schema change of adding @place to stage and will document and provide an example.
|
|-
|
|HC
|HC to report on XPointer resolver and whether we should progress it.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/384/ FR 384] : In April RW made a spreadsheet showing which elements she recommends moving into att.typed. And in...
|SB, RW
|SB and RW will review the list again.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/457/ FR 457] : KH: In the ticket I want to clarify what you use tagUsage for and what to put in a project-specifi...
|KH, LB, JC
|KH, LB, and JC will review and make a recommendation to Council before the next face-to-face.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/459/ FR 459] : This is just waiting for implementation....
|SB
|SB will implement by end of January 2014.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/465/ FR 465] : Gabby and HC seem to agree on it, and the example looks sensible. LB’s comment could be raised as ...
|HC
|HC will implement before end of January 2014.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/453/ FR 453] a place for metadata that you can't fit into existing header elements AMBER open Discussion talks mo...
|MH, PS, LB
|MH will offer DC examples and PS will offer MARC examples. LB will pull them together into some text to be inserted into the Guidelines. Given this, Council will reconsider the feature request and whether to create the wrapper element.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/384/ FR 384] that once 384 is implemented, we’ll add a note on att.typed reminding people that this is meant for ...
|HC, KH
|HC will implement [DONE]. KH will add a comment to FR 384 [DONE].
|
|-
|[https://sourceforge.net/p/tei/feature-requests/479/ FR 479] Adding the @place attribute to head and seg AMBER open JC noted that head is not meta-textual or in ...
|SR
|SR to take the ticket, and get more examples from the submitter .
|started
|-
|[https://sourceforge.net/p/tei/feature-requests/476/ FR 476] use of stage inside poetry, and using placement attribute (AMBER open). (Council agreed to @place; s...
|JC
|JC to close ticket FR 476 noting it has been resolved.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/481/ FR 481] check that all sibling att.translatable elements have @versionDate (AMBER open). (Agreed that siblin...
|SB
|SB to check whether this is implemented, and if not, get it implemented then close the ticket.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/462/ FR 462] idno@type='uri' for Linked Data AMBER open (We agreed. @type=”URI” alongside @type=”URL”) EM: The su...
|HC
|HC to implement this and close the ticket FR 462.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/471/ FR 471] extend the possible usages of argument (AMBER open). (If the intended use case is encoder-supplied a...
|LB, MH
|
|
|-
|[https://sourceforge.net/p/tei/feature-requests/472/ FR 472] docDate in dateline ? EM: dateline does not allow docDate, but byline allows docAuthor. This is inco...
|MH
|MH to add docDate to dateline, and clarify with usage notes [Done].
|
|-
|[https://sourceforge.net/p/tei/feature-requests/360/ FR 360] New attribute @keepHyphen. Ticket open, ticket GREEN, it’s rejected throughout the comments....
|PS
|PS to provide an example of the mechanism recommended to handle the use-case.
|
|-
|
|LB
|LB to add the new elements and the documentation ahead of the next release; documentation need only be at the element level, along with some brief introduction in the Guidelines, to be expanded to a full section later.
|
|-
|[https://docs.google.com/document/d/1766WTJV2xcfANh8HRZW5m520yrC1nCzQJzUgKpwiylI/edit TEI Roma Replacement Specification] JC: The existing Roma is dated and flawed, as we all know. Many tickets have come up which we cannot...
|JC
|ALL Council to go through the proposal again and discuss it, remembering to look at the comments, and further refine it. JC to make sure it’s tidied up. Deadline: next teleconference.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/445/ FR 445] Conversion of ODD to HTML: Examples should be aware of element renaming closed-fixed, implemented by...
|SR
|SR to add gi and att renaming to complete the ticket.
|COMPLETED FOR gi. Not possible for att.
|-
|[https://sourceforge.net/p/tei/feature-requests/443/ FR 443] @resp should be a member of att.global AMBER open. JC and SR: Global attributes should really not be...
|MH, LB
|MH and LB to agree on clarification to Guidelines to say that @resp means different things: responsibility for markup and content except when the element in question is a transcriptional element, in which case the content of the element is marked as coming from the source.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/468/ FR 468] : HC: precision expresses false precision that’s not real probability. It’s something more like cert...
|KH
|KH to add to the deprecation document the requirement to announce to the community that we plan to deprecate something and to get in touch if you object.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/468/ FR 468] : HC: precision expresses false precision that’s not real probability. It’s something more like cert...
|HC
|HC to email TEI-L.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/468/ FR 468] : HC: precision expresses false precision that’s not real probability. It’s something more like cert...
|SB
|
|
|-
|[https://sourceforge.net/p/tei/feature-requests/303/ FR 303] check the apache logs for frequent 404s (AMBER open). Action: JC to ask DS to make the TEI-C webserv...
|JC, MH
|JC to ask DS to make the TEI-C webserver logs available somewhere we can see them; then action on MH to write script to generate lists of bad links of various types. JC also to check google analytics/Webmaster tools. Deadline to report back by next conference call.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/305/ FR 305] Updating info on projects page (AMBER open). Project pages go out of date. There is a way to submit ...
|JC
|JC to ask DS to make that correction info available on each project page, along with its last-updated date if possible (and the latter should also show up on the bullet-point list).
|
|-
|[https://sourceforge.net/p/tei/feature-requests/466/ FR 466] Make it possible to add SIG labels to tickets (AMBER open). Action: JC as SIG Coordinator to tell th...
|JC
|JC as SIG Coordinator to tell the SIGs that if they wish, we can make their SIG convener a developer on SF and make it possible to assign SIG labels to tickets. Deadline: next teleconference.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/470/ FR 470] att.measurement and att.dimensions overlap (AMBER open). We are not really sure why all of these att...
|MH
|MH to move @commodity into its own class, and move measure and measureGrp to att.dimensions. Ticket to GREEN, assign to MH. [Subsequent study suggests to MH that this may be more complicated than it seems, and may have to wait on our having the ability to override valLists in attributes from attribute classes at the element level.]
|
|-
|[https://sourceforge.net/p/tei/feature-requests/442/ FR 442] Allow foreign to contain q (AMBER open). The group felt this should be rejected. Action:SR to close ...
|SR
|SR to close ticket because it’s rejected
|DONE
|-
|[https://sourceforge.net/p/tei/feature-requests/433/ FR 433] loosen content model of salute (AMBER open). SR: Underlying this was a desire for symmetry between s...
|SR
|SR will carry this out
|DONE
|-
|[https://sourceforge.net/p/tei/feature-requests/477/ FR 477] lines of poetry inside trailer (AMBER open). The request is for symmetry between head and trailer. T...
|SR
|SR to find a good way to achieve this, since what was done before with head was rather strange.
| DONE; HAVE COPIED WHAT WAS DONE WITH head.
|-
|[https://sourceforge.net/p/tei/feature-requests/383/ FR 383] where to put idno within biblStruct? (AMBER open) This is one of three tickets where KH could not fi...
|KH, SB
|KH will create a new ticket pointing to this and the other two tickets with deprecation problems (as listed on the wiki) saying we need a way to deprecate members of content model and reassign to SB to solve the three tickets using a Schematron warning, and to add @validUntil on constraintSpec.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/383/ FR 383] where to put idno within biblStruct? (AMBER open) This is one of three tickets where KH could not fi...
|SR
|SR to check how @validUntil makes the build fail when out of date, and if necessary update this mechanism so it can handle @validUntil on constraintSpec
|DONE. It applies to tei:*[@validUntil], so should just work. . (Ticket 383 will wait on all this, along with the two other tickets.)
|-
|[https://sourceforge.net/p/tei/feature-requests/366/ FR 366] rationalize content models of org and place (etc) (AMBER open). Group thinks a small group of people...
|JC, LB, SB
|JC to make ticket red, should stay with JC, and he should initiate the process, working with LB and SB.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/458/ FR 458] Make listBibl and model.biblLike member of model.personPart (AMBER open). Lou has already done items...
|LB
|close the ticket.
|DONE
|-
|[http://wiki.tei-c.org/index.php/Council_agenda_2013-11#More_Details_on_Agenda_topics bottom of wiki agenda page] ) SR: Why are we proposing using alpha and beta? MH: Because we were proposing asking the community ...
|MH, SR
|Assign MH to update the release documentation re alpha and beta, and investigate how we might add the SVN last changed date and the rev number to the bottom of pages.
|Latter bit done by SR 2013-11-14. Documentation in TCW22 updated by MH 2013-11-14.
|-
|
|JC, HC, SR, EM
|JC to approach the DH 2014 committee and find out how they would prefer us to do it, and whether it’s a good idea; and tell the Board that HC, SR and EM are prepared to be involved in organizing this along with one or more Board members.
|
|-
|
|EM
|EM to make sure this happens.
|
|-
|
|MH
|MH to get contact info on original groups and activate if possible, probably starting with French and Italian
|
|-
|
|LB
|LB to testdrive the spreadsheet.
|Spreadsheet sent to FC 2013-11-18
|-
|
|BB, RW
|BB and RW to turn into bug reports those attributes that are without examples that are high priority or need new/updated definitions.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/482/ FR 482] The term strikes back - terminology chapter (AMBER open). The ISO is working on a standard for termi...
|LB, KH, SB
|LB, KH and SB to articulate a more generic policy for TEI on the integration of external standards and will generate a one-page proposal for this policy. This should be provided to Council ahead of the next teleconference. In addition, LB, KH, and SB will check with Laurent that he wants TBX incorporated into the Guidelines as is or kept in sync in the future and what he thinks about melding into the rest of the TEI Guidelines (in language, approach, element naming conventions) or keeping it self-contained.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/405/ FR 405] Wrong schema generated (AMBER pending-accepted). This is due to a bug in the current version in Roma...
|MH
|MH to see if it has been fixed, and if so, close the ticket [DONE].
|
|-
|[https://sourceforge.net/p/tei/feature-requests/294/ FR 294] altIdentifier is deprecated within msPart (AMBER open). Action: KH to change to Green and add to the...
|KH
|KH to change to Green and add to the ticket about deprecation using Schematron along with 383, if not already done.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/264/ FR 264] altIdentifier in msPart (AMBER pending-accepted). Action: JC to change to Green and assign to himsel...
|JC
|JC to change to Green and assign to himself, then nudge Torsten for an example of an altIdentifier within an msPart.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/300/ FR 300] Move witStart et al. to model.milestoneLike (AMBER pending). Action: EM to change to red and assigne...
|EM
|EM to change to red and assigned to EM to chase up or otherwise close ticket.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/377/ FR 377] retaining punctuation marks in the text of a TEI document (AMBER open-accepted). RW says she has add...
|RW
|RW to finish the work and ask for help if necessary.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/345/ FR 345] members of model.respLike should be members of att.declarable (AMBER open-later). Breakout group ins...
|SR
|SR to make the ticket Green and go ahead and implement it, including some documentation/examples.
|DONE
|-
|[https://sourceforge.net/p/tei/feature-requests/480/ FR 480] Adding the @hand attribute to all (or most) text-containing elements (AMBER open). Breakout group wa...
|LB
|LB to respond to the ticket FR 480.
|
|-
|[https://sourceforge.net/p/tei/bugs/276/ BUG 276] internationalisation links (AMBER open). Language links at bottom of a page should take you to same ...
|JC, SB
|JC to make Green and allocate to SB.
|
|-
|[https://sourceforge.net/p/tei/bugs/594/ BUG 594] TEI-C website menu points to wrong index page for Guidelines (AMBER open). Fixed, will appear in nex...
|EM
|EM to create a ticket on the Chrome problem.
|
|-
|[https://sourceforge.net/p/tei/bugs/619/ BUG 619] tei_allPlus.rng: conflicting ID-types for attribute "id" of element "partialdiff" from namespace "ht...
|SB
|SB to double-check whether able to reproduce and report back on ticket if able to.
|
|-
|[http://wiki.tei-c.org/index.php/Text_Directionality_Draft first draft of new Guidelines sections] and questions [MH] MH summarized the genesis of this text from Providence. He noted that not only th...
|MH, LB
|Entire Council to (re)read MH’s draft before next face-to-face meeting. Once we’ve done that and agreed, someone will rewrite chapter 5 (WD) to include MH’s draft and the current section 10.6.6. LB volunteered.
|
|-
|[https://sourceforge.net/p/tei/bugs/288/ BUG 288] deprecate use of gram except as a child of gramGrp (AMBER open-accepted). [This is pending creation ...
|SB
|SB to create the new ticket and write the Schematron for this particular deprecation.
|
|-
|[https://sourceforge.net/p/tei/bugs/515/ BUG 515] Bad example of feature/@fVal (AMBER open). [Change this to RED as it’s not clear what needs changin...
|JC
|JC to check that’s been changed to RED [DONE].
|
|-
|[https://sourceforge.net/p/tei/bugs/578/ BUG 578] partial and recursive segmentation of s-units (AMBER open). [The Guidelines text is clear enough. Th...
|MH
|MH will revise content model to match the prose.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/298/ BUG 298] att.editLike should not bring att.dimensions & att.ranging (AMBER open-accepted). [MH to ask Gabriel...
|MH
|MH to ask Gabby to implement.
|
|-
|[https://sourceforge.net/p/tei/bugs/302/ BUG 302] version ignores @source (AMBER open). This is a Roma issue. Recommend marking as closed won’t fix be...
|SR
|SR to try reproducing this and set as closed-won’t fix.
|CLOSED
|-
|[https://sourceforge.net/p/tei/bugs/583/ BUG 583] Adding new attribute fails in Roma schema generation (AMBER open). Same as 302. Action: SR wil set a...
|SR
|SR wil set as closed-won’t fix and check that it has the Roma tag.
|
|-
|[https://sourceforge.net/p/tei/bugs/434/ BUG 434] issues with ePub conversion (2/3) (AMBER open). Any issue not dealing with ODD processing should be ...
|SR
|SR will ask poster kindly to post there (explaining why) and close this issue.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/212/ FR 212] Generic dating class (AMBER pending-accepted). Gabby claimed in 2011 that it’s done except needs som...
|HC, MH
|HC to investigate whether it’s actually been done. MH offered examples if needed.
|
|-
|[https://sourceforge.net/p/tei/bugs/528/ BUG 528] consistency in "the Guidelines" vs. "these Guidelines" (AMBER open). This should be green. Action: K...
|KH
|KH to do this.
|
|-
|[https://sourceforge.net/p/tei/bugs/548/ BUG 548] use of modal verbs in Guidelines (AMBER pending-later). Already assigned to KH. RW agreed to help. I...
|KH, RW, LB
|KH and RW to create a new, detailed ticket with all questionable cases. In the meantime, LB will fix the edits that KH made at r12525.
|
|-
|[https://sourceforge.net/p/tei/bugs/568/ BUG 568] "How to edit the Guidelines" and chapter organization (AMBER open). SR: What MH found looks distinct...
|MH
|MH to replace references to entity references with explanation of XIncludes in “How to edit the Guidelines” [DONE].
|
|-
|[https://sourceforge.net/p/tei/bugs/585/ BUG 585] Precision element missing att.ranging class (AMBER open). Working group closed. Action: EB to ask Ga...
|
|EB to ask Gabby to open a new one about clarifying this element and relevant parts of the chapter on dating, to explain and exemplify the use of these attributes.
|
|-
|[https://sourceforge.net/p/tei/bugs/589/ BUG 589] add respons and space to att.responsibility (AMBER open). Working group triage: Is it ok to add have...
|EM
|EM will get rid of locally assigned @resp by adding to att.responsibility (thereby getting @cert as well). Will change to GREEN.
|
|-
|[https://sourceforge.net/p/tei/bugs/506/ BUG 506] Meaning of @corresp rather in dispute (AMBER open). Working group triage: needs to be discussed: Is ...
|MH
|MH to create an example and run it by tei-council before adding to the Guidelines.
|
|-
|[https://sourceforge.net/p/tei/bugs/563/ BUG 563] inconsistent encoding of citations to sources of examples (AMBER open). Working group recommends ass...
|BB, EM, PS
|BB, EM, and PS to work on the ticket by mid-February 2014.
|
|-
|[https://sourceforge.net/p/tei/bugs/582/ BUG 582] Need for consistency in terminology relating to TEI conformance (AMBER open). Working group: Agreed ...
|MH
|MH to deal with the ticket narrowly, using a hyphen and lowercase but leaving both “conformant” and “conformable” [DONE].
|
|-
|[https://sourceforge.net/p/tei/bugs/582/ BUG 582] Need for consistency in terminology relating to TEI conformance (AMBER open). Working group: Agreed ...
|JC
|JC will create a ticket to reconsider the discussion of “conformable” and “conformant” in the Guidelines.
|
|-
|[https://sourceforge.net/p/tei/bugs/460/ BUG 460] list/@type="unordered" is not recommended, but used often (AMBER open). Working group: This bug has...
|MH
|MH to follow the last comment on ticket to figure out our current situation.
|
|-
|[https://sourceforge.net/p/tei/bugs/468/ BUG 468] Order of elements in publicationStmt (AMBER open-accepted). Group discussion: SB: Despite Lou’s comm...
|SB, LB
|SB will do the content model and LB will do the prose. They’ll work out the specifics.
|
|-
|
|
|TS to come up with a more detailed problem description and what the WG should attempt to solve by 2014-01-01.
|
|-
|[https://sourceforge.net/p/tei/bugs/581/ BUG 581] `attRef` needs better documentation (AMBER open). Action: SR to implement either removal of attRef, ...
|SR, MH
|SR to implement either removal of attRef, MH to adjust documentation.
|
|-
|[https://sourceforge.net/p/tei/bugs/405/ BUG 405] XPointer schemes may not nest, but see ch. 16 (AMBER open). Action: SB to fix documentation....
|SB
|SB to fix documentation.
|
|-
|[https://sourceforge.net/p/tei/bugs/601/ BUG 601] att.patternReplacement/@matchPattern should be XPath regex, not XML Schema (AMBER open). Action: JC ...
|JC
|JC to close as a dupe of FR 432.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/432/ FR 432] Change regex flavor on @matchPattern (GREEN open). Agreed, XPath. Action: MH Write to TEI-L list, if...
|MH
|MH Write to TEI-L list, if no negative feedback, change.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/469/ FR 469] add extent to att.dimensions (GREEN open). Agreed. Action: LB to provide an example in HD chapter (2...
|LB
|LB to provide an example in HD chapter (2.2.3) and close ticket.
|DONE
|-
|[https://sourceforge.net/p/tei/feature-requests/460/ FR 460] Use of geogFeat in transcription? (GREEN open). Ok. Action: JC to do it before next teleconference....
|JC
|JC to do it before next teleconference.
|
|-
|[https://sourceforge.net/p/tei/bugs/605/ BUG 605] clarifying add vs. supplied and del vs. surplus (AMBER open). Action: HC to emend the prose of the p...
|HC, LB
|HC to emend the prose of the paragraph beginning "The add element should not be used" to reference the surplus element also; LB points out that the specList can't be modified, because supplied/surplus aren't defined in Core.
|
|-
|[https://sourceforge.net/p/tei/bugs/609/ BUG 609] "lemma" used in a confusing way in CriticalApparatus.xml (AMBER open). Action: LB to remove the phra...
|LB
|LB to remove the phrase "on any one lemma" from the @varSeq description.
|DONE
|-
|[https://sourceforge.net/p/tei/bugs/610/ BUG 610] "lem" used in a confusing way in CriticalApparatus.xml (AMBER open). Action: BB to remove the last c...
|BB
|BB to remove the last clause of the sentence in question, beginning ", or to make clear".
|
|-
|[https://sourceforge.net/p/tei/bugs/558/ BUG 558] name/orgName (AMBER open). Action: RW to ask PS where he is on this; change ticket status to GREEN....
|RW, PS
|RW to ask PS where he is on this; change ticket status to GREEN.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/474/ FR 474] add an exemplum for @ref (GREEN open). Action: JC to poke JC; deadline by next teleconference....
|JC
|JC to poke JC; deadline by next teleconference.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/475/ FR 475] Stop using attributes to store space-delimited values (GREEN open). Nothing wrong with space-delimit...
|JC
|JC to Close as Closed-rejected.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/461/ FR 461] Two small improvements to `recording` (GREEN open). Action: LB to do this by next teleconference....
|LB
|LB to do this by next teleconference.
|DONE
|-
|[https://sourceforge.net/p/tei/feature-requests/467/ FR 467] Make @name optional on tei:relation (GREEN open). Action: SR has already done this....
|SR
|SR has already done this.
|
|-
|[https://sourceforge.net/p/tei/bugs/216/ BUG 216] half title pages in TEI Tite (AMBER open-postponed). KH has to finish comparing TEI-Tite with the Ap...
|KH
|KH to resolve Tite problems and report regularly to Council on progress.
|
|-
|[https://sourceforge.net/p/tei/bugs/216/ BUG 216] half title pages in TEI Tite (AMBER open-postponed). KH has to finish comparing TEI-Tite with the Ap...
|
|Council to ask for reports before each meeting.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/478/ FR 478] loosening content and model of `signed` (GREEN open). Agree that is is green. Though would model.div...
|SR
|SR to implement signed at top as well as bottom [DONE].
|
|-
|[https://sourceforge.net/p/tei/feature-requests/280/ FR 280] clarification of colloc (GREEN pending-accepted). #1 is already done. #2: Breakout group agreed that...
|KH
|KH to remove @type from both examples, etc.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/389/ FR 389] clarify definition of @from on locus and biblScope (GREEN open). EM admits to sloth and will do so. ...
|EM
|EM to do before next teleconference.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/401/ FR 401] extend and clarify use of particDesc and settingDesc (GREEN open). JC admits sloth and will implemen...
|JC
|JC to implement before next teleconference; Council decides it might be better to add these (model.
|
|-
|[http://wiki.tei-c.org/index.php/TEI_Cheatsheets Cheatsheets: Short best/recommended practice documents] EM: Not cheatsheets - negative implication. RW: Quick Start. HC: Quick Reference; SB: “Guidelettes” ...
|EM
|EM to ask MB to clarify what she wants from Council with regard to helping cheatsheets.
|
|-
|[https://sourceforge.net/p/tei/feature-requests/482/ FR 482] Earlier we decided:Action: LB, KH and SB to articulate a more generic policy for TEI on the integrat...
|LB, KH, SB
|LB, KH and SB to articulate a more generic policy for TEI on the integration of external standards and will generate a one-page proposal for this policy. This should be provided to Council ahead of the next teleconference. In addition, LB, KH, and SB will check with Laurent that he wants TBX incorporated into the Guidelines as is or kept in sync in the future and what he thinks about melding into the rest of the TEI Guidelines (in language, approach, element naming conventions) or keeping it self-contained.
|
|-
|[http://sourceforge.net/p/tei/feature-requests/378/ FR 378] ; c.f. A Generic Formalism for Encoding Standoff annotations in TEI). Action: JC to ask Peter Stadle...
|JC, HC, SB
|JC to ask Peter Stadler if he’d like to attend as Council rep; otherwise any interested members of Council (HC,SB) are encouraged to attend virtually.
|
|-
|
|SB, LB
|SB and LB would like to (re?-)join the task force. Council advises them to keep in mind the work by the Ontology/MS SIGs, in particular Torsten Schassan, on an ‘object’ or ‘objectDesc’ element.
|
|-
|[https://sourceforge.net/p/tei/bugs/229/ BUG 229] Check desc of all xs:anyURI atts for in-doc restrictions (GREEN pending). We got rid of data.code al...
|JC
|JC to check prose discussion all xsd:anyURI attributes by next teleconference.
|
|-
|[https://sourceforge.net/p/tei/bugs/312/ BUG 312] i18n revision due (GREEN open). Action: MH, when he completes action on related ticket (perhaps afte...
|MH
|MH, when he completes action on related ticket (perhaps after moving notes from minutes into tickets), to update this ticket.
|
|-
|[https://sourceforge.net/p/tei/bugs/442/ BUG 442] update ODD documentation on www.tei-c.org and in Guidelines (GREEN open). Action: MH to finish it....
|MH
|MH to finish it.
|
|-
|[https://sourceforge.net/p/tei/bugs/336/ BUG 336] AdBlock blocks 'msad' ID (GREEN pending-later). Per last comment, time has passed and nothing else h...
|JC
|JC to close ticket.
|
|-
|[https://sourceforge.net/p/tei/bugs/587/ BUG 587] Guidelines version info on pages should link better (GREEN open). Action: JC to carry out his last c...
|JC
|JC to carry out his last comment on the ticket.
|
|-
|[https://sourceforge.net/p/tei/bugs/519/ BUG 519] Make lb, pb, cb, gb consistent (GREEN open-accepted). Council decided to close. Action: JC to close ...
|JC
|JC to close [DONE].
|
|-
|[https://sourceforge.net/p/tei/bugs/441/ BUG 441] fDecl doesn't allow att.datcat yet (GREEN open-accepted). Action: MH to prod Piotr....
|MH
|MH to prod Piotr.
|
|-
|[https://sourceforge.net/p/tei/bugs/525/ BUG 525] citedRange and biblScope should share att class (GREEN open). SB admitted to sloth. Action: SB to co...
|SB
|SB to complete.
|
|-
|[https://sourceforge.net/p/tei/bugs/525/ BUG 525] citedRange and biblScope should share att class (GREEN open). SB admitted to sloth. Action: SB to co...
|MH, JC, KH
|MH to check Allura settings to make sure that the owners of both bugs and feature requests receive email notifications. [JC and KH looked into this during a break and might have fixed it through another mechanism. MH to check with JC].
|
|-
|[https://sourceforge.net/p/tei/bugs/418/ BUG 418] Names and Dates chapter does not mention calendar (GREEN open). Action: JC will add the prose before...
|JC
|JC will add the prose before the next teleconference.
|
|-
|[https://sourceforge.net/p/tei/bugs/401/ BUG 401] Most attributes lack good examples (GREEN open-accepted). This was previously discussed. Action: RW ...
|RW
|RW to follow up.
|
|-
|[https://sourceforge.net/p/tei/bugs/387/ BUG 387] clarifying heading or title of a graphic (GREEN open). LB recently posted a comment approving of the...
|BB
|BB will implement the ticket.
|
|}
[[Category:Council]]

XML Whitespace

2013-11-16T16:56:16Z

Rahtz: /* XSLT Normalization Code */

TEI has robust features for specifying space, gaps, line breaks, and related aspects of the space between text. But TEI is an XML vocabulary, and XML itself, and programs that read and process XML files, have their own ways to deal with what they call whitespace, that is, space, tab, carriage return and linefeed characters. Sometimes the standards, constraints, and conventions imposed by XML cause problems for TEI encodings and for programs that process TEI files.

This article explains interactions between TEI and XML's treatment of whitespace and concludes with recommendations for both producers of TEI encodings and authors of programs that process TEI encodings.

==Where XML Considers Whitespace to be Significant==

In XML documents, some whitespace is significant, some is not. For example, inside the brackets that mark XML elements extra whitespace is not significant. For any program processing these as pieces of XML,

<tt><title type="main"></tt>

and

<tt><title     type = "main" ></tt>

are the same. There is no significance to the extra space. By XML rules, no application that processes the data in this XML file (processing it as XML and not just as text) is allowed to treat these two representations differently. A person or computer editing this file is free to use either one, based merely on readability and aesthetics. The fact that there is whitespace between <tt>title</tt> and <tt>type</tt> is significant, but how much or of what kind (space characters, tabs, carriage returns, new lines) is not significant. The space between <tt>type</tt> and <tt>=</tt> is not significant.

Whitespace can be significant, however, in the content of an element. For example,

<tt><name>JoAnn</name></tt>

and

<tt><name>Jo Ann</name></tt>

are different because of that space between <tt>Jo</tt> and <tt>Ann</tt>, and any program reading this element in an XML file is obliged to maintain the distinction.

But things can get complicated. Consider this:

<persName> 
 <forename>Jo</forename>
 <forename>Ann</forename>
 <surname>Henry</forename>
</persName>

Should the carriage returns and new lines matter? Should it matter if that
open area before <tt><surname></tt> is a tab or is instead four space characters? Should it matter that there is extra space after <tt><persName></tt>?

== Normalize = Collapse + Trim ==

Many applications, including web browsers and many programs that read XML files will, unless instructed otherwise, “collapse” XML whitespace, that is, they will replace any contiguous string of space characters (0x20), tabs (0x09), carriage returns (0x0D) and line feeds (0x0A) with just one space character. So

<name>Jo Ann</name>

<name>Jo Ann</name>

<name>Jo
 Ann</name>

would all be treated as if there were just one space character between <tt>Jo</tt> and <tt>Ann</tt>. Moreover many applications will remove, or “trim”, leading and trailing XML whitespace. So these, too,

<name> Jo Ann</name >

<name>
 Jo Ann</name>

<name>
 Jo 
 Ann
</name>

would be treated as if the XML had been simply <tt><name>Jo Ann</name></tt>.

Sometimes, as in the XSLT function “normalize-space()”, the term “normalize” refers to the combination of collapsing XML whitespace and then trimming. Other times, as in XML Schema, “collapse” is the name of the combined operation. This article uses the XSLT terminology: normalizing is collapsing plus trimming.

Normalizing XML whitespace is very common. It is so pervasive that it is easy to overlook that it is happening and even difficult to know which program processing an XML file is doing the normalizing—is it the XSLT processor, the XSL program, the web browser, the print routine, or some combination?

== @xml:space ==

[http://www.w3.org/TR/REC-xml/#sec-white-space The XML specification] defines an attribute, <tt>xml:space</tt>, that when set to <tt>preserve</tt> instructs applications to suspend default trimming, collapsing, and normalizing and instead keep all the spaces, tabs, carriage returns, and line feeds just as they are. If <tt>xml:space</tt> is set to default or is simply left off, no such request is made; the application is free to do whatever its developer thinks best.

The attribute <tt>xml:space</tt> is inherited by child elements. One could, for example, put <tt>xml:space="preserve"</tt> into a TEI <tt><text></tt> element but not in <tt><teiHeader></tt>, to indicate that the request applies to all of the text but to none of the header.

TEI allows <tt>xml:space</tt> to be used [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-att.global.html on any element]. But since TEI has so much rich functionality for encoding spaces, gaps, line breaks, and so on, the <tt>xml:space</tt> attribute is rarely used. Whatever could be accomplished by setting its value to <tt>preserve</tt> would be better accomplished by using native TEI elements. So the value is normally left as <tt>default</tt> by simply not including the attribute. Downstream processors are then left free to treat XML whitespace however the application developers want.

== Default Whitespace Processing ==
When <tt>xml:space</tt> is left as <tt>default</tt>, '''nothing in XML or TEI specifies how consumers of a TEI XML file should treat whitespace.'''

There are, however, unspecified conventions. TEI encodings generally assume that space will be normalized, that in this encoding

 
 We hold these truths to be self-evident, that all men are 
 are created equal, that they are endowed by their creator 
 with certain inalienable Rights, that among these are Life, 
 Liberty and the pursuit of Happiness.


some downstream processor will collapse spaces, tabs, carriage returns, and line feeds and will trim the space just after the <tt></tt> and just before the <tt></tt>, and that in this encoding, [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-persName.html from the TEI 5 Guidelines],

<persName>
 <forename>Edward</forename>
 <forename>George</forename>
 <surname type="linked">Bulwer-Lytton</surname>, <roleName>Baron Lytton of
 <placeName>Knebworth</placeName>
 </roleName>
</persName>

the man's name is <tt>Edward George Bulwer-Lytton, Baron Lytton of Knebworth</tt>, and not <tt> Edward George Bulwer-Lytton, Baron Lytton of Knebworth </tt> with space on the outsides, or <tt>EdwardGeorgeBulwer-Lytton,BaronLyttonofKnebworth</tt>, or some name with carriage returns in it.

=== Collapsing ===

A TEI encoder should assume that any string of whitespace characters will be collapsed into one space character. In theory, this can be circumvented by setting <tt>xml:space='preserve'</tt>, but not all downstream processors honor such requests. Web browsers, for example, do not. It is safer to use TEI's <tt><space></tt> element.

Programmers of downstream applications should feel free to collapse whitespace but should also honor <tt>xml:space='preserve'</tt> unless they can be certain that doing so is unnecessary.

=== Trimming ===

Whether text in an element should or will be trimmed depends on whether it is the only text in the element or it has siblings that are themselves elements.

==== Text-Only Elements ====

Even when specifications may be unclear on the matter, XML culture, conventions, product features, programming habits, and general best practices are allied not only to collapse but to trim whitespace from elements that contain only text. Encoders and consumers of TEI data should accept this. Unless <tt>@xml:space</tt> has been set to <tt>'preserve'</tt>, consumers of TEI files should trim such space and encoders should assume such space will be trimmed.

When this is done, these encodings

<country>Australia</country>

<country> Australia </country>

<country>
 Australia 
<country>

will all produce the same result. If the processing software were extracting data for use in a database, the resulting field would be <tt>country: Australia    </tt> in all three cases. If an encoder wants leading and trailing space to be preserved, if, for example,

<tt><emph rend='underline'> Yes! <emph></tt>

is meant to underline the space before and after the word, then <tt>xml:space='preserve'</tt> must be included in the <tt><emph></tt> element '''and''' it must be ensured that downstream processors actually honor <tt>xml:space='preserve'</tt>. If the underlining is meant to extend for not one but several spaces, only heroic care by encoder and consumer will ensure that it does. Use of <tt><space rend='underline'></tt> will be more reliable.

With both collapsing and trimming—that is, with normalizing—all of the following encodings would yield the same result.

<name>Ralph Waldo Emerson</name>

<name> Ralph Waldo Emerson </name>

<name>
 Ralph 
 Waldo 
 Emerson 
<name>

==== Mixed-Content Elements ====

If an element contains not just text, but other elements, where and when space should be trimmed is more complicated. Consider the following encoding.

  The <emph> cat </emph> ate  the <foreign>grande croissant</foreign>. I didn't!
 

The <tt></tt> element contains five child nodes.
{| class="wikitable"
|-
| <tt>      </tt><tt>  The </tt>
|| A text node
|-
| <tt>            </tt><tt><emph> cat </emph></tt>
|| An <tt><emph></tt> element that itself contains one text node
|-
| <tt>                              </tt><tt> ate  the </tt>
|| A text node
|-
| <tt>                                        </tt><tt><foreign>grande croissant</foreign></tt>
|| A <tt><foreign></tt> element that itself contains one text node
|-
| <tt>                                                                           . I didn't!      </tt>
|| A text node that includes a carriage return and then two spaces
|-
|}

By convention, it is presumed that this encodes a passage that could have been equivalently encoded one of these ways:

The 
<emph>cat</emph>
ate the 
<foreign>croissant</foreign>. 
I didn't!

The <emph>cat</emph> ate the <foreign>grande croissant</foreign>. I didn't!

The algorithm to normalize space in mixed content is:
* Collapse all white space, then
* trim:
** trim leading space on the first text node in an element and
** trim trailing space on the last text node in an element,
** trim both if a text node is both first and last, i.e., is the only text node in the element.

Applying that algorithm to the above passage:
{| class="wikitable"
|-
| <tt>      </tt><tt>  The </tt> 
<tt>        </tt><tt>The </tt>
|| Because this is the first node in the element, leading space is trimmed and trailing space is collapsed but not trimmed.
|-
| <tt>            </tt><tt><emph> cat </emph></tt> 
<tt>                   cat      </tt>
|| Because the only thing inside the <emph> element is a text node, the text there gets collapsed and trimmed.
|-
| <tt>                               </tt><tt> ate  the </tt> 
<tt>                               </tt><tt> ate the </tt>
|| Space is collapsed but not trimmed on either side.
|-
| <tt>                                        <foreign>grande croissant</foreign></tt> 
<tt>                                                 grande croissant</tt>

|| Space in this text-only node is collapsed and trimmed, but no change results.
|-
| <tt>                                                                         . I didn't!</tt> <tt>     </tt> 
<tt>                                                                         . I didn't!</tt>
|| Because this is the last node in the element, trailing space is trimmed and leading space is collapsed but not trimmed.
|-
|}
The result is as if the encoding had been
The <emph>cat</emph> ate the <foreign>grande croissant</foreign>. I didn't!

'''Note:''' The normalization process would have corrupted the text had the encoder put spaces ''inside'' the <emph>, like this:
The<emph> cat </emph>ate the <foreign>grande croissant</foreign>. I didn't!

The resulting text would be:

Thecatate the ''grande croissant''. I didn't!

'''An encoder should assume that an element that includes nothing but text ''will'' get trimmed.'''

== Structured Elements and xsl:strip-space ==

As mentioned above, normalization of whitespace is very common. Programmers implement it without asking encoders. And encoders presume some downstream application will effect it. This complex encoding of a person's name, [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-persName.html taken from the TEI 5 Guidelines] and mentioned above,

<persName>
 <forename>Edward</forename>
 <forename>George</forename>
 <surname type="linked">Bulwer-Lytton</surname>, <roleName>Baron Lytton of
 <placeName>Knebworth</placeName>
 </roleName>
</persName>

presumes—though without saying so—that a downstream program will normalize space according to the algorithm above and produce the name <tt>Edward George Bulwer-Lytton, Baron Lytton of Knebworth</tt>.

Note here that the <tt><persName></tt> element contains both text and elements. Note the comma. And note that had the forenames been encoded without intervening whitespace, the result would have been <tt>EdwardGeorge</tt>.

A problem lurks. Part of defining an XML vocabulary such as TEI is specifying whether an element may contain text and elements or just elements. In TEI 5, <tt><address></tt>, for example, unlike <tt><persName></tt>, may only contain other elements. This

<address>
 <street>10 Downing Street</street>
 <settlement>London</settlement>
 <postCode>SW1A 2AA</postCode>
<address>

is valid TEI. But this

<address>
 <street>10 Downing Street</street>,
 <settlement>London</settlement>
 <postCode>SW1A 2AA</postCode>
<address>

is not, because of that comma after the <tt><street></tt> element. Free non-whitespace text is not allowed between the elements that comprise the <tt><address></tt> element. Though the term is sometimes used more loosely, <tt><address></tt> would commonly be called a "structured element."

Elements that do not allow free non-whitespace text—structured elements, strictly speaking—mimic database records. When XML is used to move data between databases, such elements are the norm; indeed many XSLT programmers have never worked on anything but structured data. In a TEI file, structured data is more common in the header than in the text. A program extracting metadata from a TEI file will often be looking for structured data in the header, so that it can populate database fields, maybe like this:

street: 10 Downing Street 
settlement: London 
postCode: SW1A 2AA 

Defining an element as a structured element specifies that space between child elements can be completely ignored. Thus these two encodings

<address>
 <settlement type="city">London</settlement>
 <postCode>SW1A 2AA</postCode>
<address>

<address>
 <settlement type="city">London</settlement><postCode>SW1A 2AA</postCode>
<address>

are equivalent. They encode:

city: London 
postCode: SW1A 2AA 

Nothing in the encoding indicates that there should be a space, a comma, a new-line, or anything else between "London" and "SW1A 2AA". What, if anything, will be there is left to the processing application. When rendering prose, the application might insert a comma; when printing a mailing label, it might insert a new-line. If might use different punctuation when mailing to different countries.

To correctly process structured elements, XSL programmers insert an instruction, <tt><xsl:strip-space></tt>, at the beginning of their programs, followed by a list of the names of the structured elements. Among other things, this ensures that all whitespace between the children of structured elements will be removed. It will be as if such whitespace was collapsed and trimmed and made to completely disappear.

This situation can produce a temptation best resisted. An encoder may want to request that space be inserted between the components of a structured element, that, for example,

<address>
 <settlement type="city">London</settlement>
 <postCode>SW1A 2AA</postCode>
<address>

should be taken to encode "London SW1A 2AA". To implement this, the downstream processor could simply treat <tt><address></tt> as if it were not a structured element and was a mixed-content element instead. The encoder could then leave whitespace between the child elements and the regular normalization algorithm described above would collapse it and leave one space character.

The temptation is all the more seductive because (1) XML verification will not signal an error, (2) demands on the programmers of downstream applications are reduced, and (3) it is easy to succumb unknowingly. In XSLT, the programmer intentionally or inadvertently leaves <tt><xsl:strip-space></tt> off, something the programmer is happy to do since gathering the list of structured elements was inconvenient anyway, and all seems to be well.

But the better practice is indeed to burden the application with properly formatting structured elements. This burden is part of what it means for an element to be structured. If the project team agrees that whitespace in structured elements will be significant, the schema should be customized to make these elements mixed-content elements instead of structured elements. This ensures that future users of the XML files will be able to understand the files' contents. It also signals that

<tt><settlement>New</settlement><settlement>York</settlement></tt>

and

<tt><settlement>New</settlement> <settlement>York</settlement></tt>

are different, which they would not be if the element were a structured one.

== Recommendations ==

* Programmers should, unless instructed otherwise by <tt>@xml:space='preserve'</tt>, implement code that normalizes space.
* Encoders should presume such normalization will be done but should include a note in <tt><encodingDesc></tt> announcing the presumption. If normalization is not desired as the default, this certainly should be announced in <tt><encodingDesc></tt>
* Encoders should use <tt>xml:space='preserve'</tt> only with the utmost care. Whatever could be accomplished by using it is usually accomplished with less risk by using native TEI elements.
* Project teams should not intentionally or inadvertently use structured elements as if they were mixed-content elements. If this must be done, the schema should be customized to record the change.

== XSLT Normalization Code ==

To normalize mixed-content elements, XSLT's <tt>normalize-space()</tt> function cannot simply be used on all text nodes. The XSLT stylesheet must consider where a text node is among its siblings.

The following XSLT 1.0 code implements the normalization algorithm described above. It works for both text-only and mixed-content elements. The code overrides the built-in template for the appropriate text nodes so may simply be added to XSLT stylesheets.
<pre>

<xsl:template match="text()[not(ancestor::*[@xml:space][1]/@xml:space='preserve')]">

<xsl:if test="position()!=1 and normalize-space(substring(., 1, 1)) = '' and normalize-space()!=''">
<xsl:text> </xsl:text>
</xsl:if>
<xsl:value-of select="normalize-space()"/>

<xsl:if test="position()!=last() and position()!=1 and normalize-space(substring(., string-length())) = ''
or position()!=last() and position() =1 and normalize-space(substring(., string-length())) = '' and normalize-space()!=''
or last()=1 and string-length()!=0 and normalize-space()='' ">
<xsl:text> </xsl:text>
</xsl:if>
</xsl:template>
</pre>
The <tt>normalize-space(substring(., string-length())) = <nowiki>''</nowiki></tt> is just a way to test for whitespace.

An alternative in XSLT 2.0 is the code below, which covers all uses of <tt>text()</tt>. it is written in a slightly more verbose style than the XSLT 1.0 version.

<pre>
<xsl:template match="text()">
<xsl:choose>
<xsl:when
test="ancestor::*[@xml:space][1]/@xml:space='preserve'">
<xsl:value-of select="."/>
</xsl:when>
<xsl:otherwise>

<xsl:if test="position()!=1 and matches(.,'^\s') and normalize-space()!=''">
<xsl:text> </xsl:text>
</xsl:if>
<xsl:value-of select="normalize-space(.)"/>
<xsl:choose>

<xsl:when test="last()=1 and string-length()!=0 and normalize-space()=''">
<xsl:text> </xsl:text>
</xsl:when>

<xsl:when test="position()!=1 and position()!=last() and matches(.,'\s$')">
<xsl:text> </xsl:text>
</xsl:when>

<xsl:when test="position()=1 and matches(.,'\s$') and normalize-space()!=''">
<xsl:text> </xsl:text>
</xsl:when>
</xsl:choose>
</xsl:otherwise>
</xsl:choose>
</xsl:template>
</pre>

== External Links ==
*[http://www.w3.org/TR/REC-xml/#sec-white-space XML 1.0 (Fifth Edition W3C Recommendation 26 November 2008) 2.10 White Space Handling] The spec on @xml:space.
*[http://www.jenitennison.com/blog/node/41 Things that make me scream: xml:space="preserve" in WordML] Frustrations of dealing with @xml:space.
*[http://lists.xml.org/archives/xml-dev/201207/msg00172.html What is @xml:space about?] A discussion of @xml:space on xml-dev.
*[http://msdn.microsoft.com/en-us/library/ms788746(v=vs.90).aspx Whitespace Processing in XAML] Another description of the algorithm for normalizing mixed-content elements.

[[Category:XSLT]]
[[Category:Markup]]
[[Category:Recommended Practice]]

Council agenda 2013-11

2013-11-11T10:02:06Z

Rahtz: /* Monday 11 November 2013 */

Map of locations: https://mapsengine.google.com/map/edit?mid=z5kNNI17e3DU.kEaB-XyBbZ-A

Open Google Doc Minutes at: https://docs.google.com/document/d/1F0pOZ5PkWvIfnPgAKCONRdrDZhl4dkig_zqCiPvUG8A/edit?usp=sharing

== Sunday 10 November 2013 ==
* Evening plans: From 6pm JamesC will be in The Royal Oak http://www.theroyaloakoxford.co.uk/ 42-44 Woodstock Road, Oxford, OX2 6HT
** And a good time was had by Kevin, Syd, Paul, Martin, and Martin’s brother Nick. Thank you, James; you’re a great pub-host!

== Monday 11 November 2013 ==
* 09:00 - 10:30 Morning Discussion Session
**Topics Including:
** EEBO TCP: Reaching consensus with EEBO TCP [SR] (see http://tei.oucs.ox.ac.uk/EEBO/ for summary of problem, and links to tickets)
*** Although the above link does have links to tickets and what I think is probably a set of summaries of particular problems, it does not provide a summary of '''the''' problem. Could someone (SR, JC, PS?) explain the big picture, here — what is the exact task (making sure EEBO TCP is TEI P5 conformant?), and why is it important?
** Report on specification and estimated cost for XPointer resolver [HC/SB]
** Report on specification and estimated cost for oXygen front end for ODD [SB/EM]
* 10:30 - 10:45 Break
* 11:45 - 12:30 SourceForge Tickets
* 12:30 - 14:00 Lunch Break (in Meeting Room)
* 14:00 - 15:30 Afternoon Discussion Session
**Topics Including:
** Pure ODD is there a link for what pure ODD entails? yes, at the bottom of the Wiki
** TEI Roma Replacement Specification
* 15:30 - 15:45 Break
* 15:45 - 17:30 SourceForge Tickets
* 19:00 -- "Sojo", Szechuan/Shanghainese/Cantonese restaurant, website at http://www.sojooxford.co.uk/ claims vegetarian menu on request. SoJo (Chinese) http://www.sojooxford.co.uk/ 6/9 Hythe Bridge Street, Oxford, OX1 2EW

== Tuesday 12 November 2013 ==
* 09:00 - 10:30 Morning Discussion Session
**Topics Including:
** Release Process (see below)
** Ideas on how to run an experimental TEI Hackathon [SR]
* 10:30 - 10:45 Break
* 11:45 - 12:30 SourceForge Tickets
* 12:30 - 14:00 Lunch Break (in Dining Room)
* 14:00 - 15:30 Afternoon Discussion Session
**Topics Including:
** Text Directionality Workgroup: look at [[Text Directionality Draft|first draft of new Guidelines sections]] and [[Text Directionality Draft Questions|questions]] [MH]
** Into the blue yonder: is it time to have a TEI P6 discussion again? [SR]
* 15:30 - 15:45 Break
* 15:45 - 17:30 SourceForge Tickets

* Evening: A meal chez Rahtz, 8pm directions and description to follow.

== Wednesday 13 November 2013 ==
* 09:00 - 10:30 Morning Discussion Session
** Cheatsheets: Short best/recommended practice documents
** From 09:30: Discussion with Torsten Schassan (via skype) about need for Object Description Chapter (see http://wiki.tei-c.org/index.php?title=Council_agenda_2013-11-OntologySIG)

* 10:30 - 10:45 Break
* 11:45 - 12:30 SourceForge Tickets
* 12:30 - 14:00 Lunch Break (in Meeting Room)
* 14:00 - 15:30 Afternoon Discussion Session
**Topics Including:
** LingSIG Meeting and Modelling / Serializing standoff (c.f. http://sourceforge.net/p/tei/feature-requests/378/ )
** Terminology Chapter, TBX, and https://sourceforge.net/p/tei/feature-requests/482/
* 15:30 - 15:45 Break
* 15:45 - 16:30 SourceForge Tickets

*Evening -- The Rickety Press http://www.thericketypress.com, 67 Cranham Street, Oxford, OX2 6DE

== More Details on Agenda topics ==

* Discuss possible revisions to [http://www.tei-c.org/Activities/Council/Working/tcw22.xml#releaseSteps step-by-step instructions in release procedure]
** Should step 1 (creating P5/ReleaseNotes/readme-X.X.X.xml) happen at the same time as step 4 (freeze on commits)?
** Should we do steps 1 through 5 farther in advance so we can check that the version numbers etc. show up in the right places in files resulting from the build process?
** Immediately after a release, should we change the version number in the repository to next release number (e.g., "2.5a", with "a" for "alpha") so people won't be confused looking at the last successful build and seeing the old version number. Then immediately before a release, when we put out the call to TEI-L to look for typos, we can change the "a" to "b" (e.g., "2.5b") and then when we actually release, remove the "b".
** Should we have the date of a build be auto-generated? It will make it clearer that people are looking at something that's evolving, and it will also make it easier to diagnose the occasional case where one of the Jenkins servers stops updating.
* [https://sourceforge.net/p/tei/feature-requests/378/?page=2 proposals for <standoff>] -- have Javier join the discussion?

* i18n: how to take forward updating of the translations

* Development of Pure ODD [LB and SR]. See paper at http://tei.oucs.ox.ac.uk/Talks/2013-09-acmdoceng/rahtzburnard.pdf and the code at https://github.com/TEIC/pureodd

* Ideas on how to run an experimental TEI Hackathon [SR]

* Into the blue yonder: is it time to have a TEI P6 discussion again? [SR]

* Reaching consensus with EEBO TCP [SR] (see http://tei.oucs.ox.ac.uk/EEBO/ for summary of problem, and links to tickets)

* Report on new Roma Specification [JC]

* Report on specification and estimated cost for XPointer resolver [HC/SB]

* Report on specification and estimated cost for oXygen front end for ODD [SB/EM]

* Cheatsheets: Short best/recommended practice documents

* Text Directionality Workgroup: look at [[Text Directionality Draft|first draft of new Guidelines sections]] and [[Text Directionality Draft Questions|questions]] [MH]

Council agenda 2013-11

2013-11-01T10:59:39Z

Rahtz: /* Agenda topics */

== Sunday 10 November 2013 ==
* Evening plans: From 6pm JamesC will be in The Royal Oak http://www.theroyaloakoxford.co.uk/ 42-44 Woodstock Road, Oxford, OX2 6HT

== Monday 11 November 2013 ==
* 09:00 - 10:30 Morning Discussion Session
**Topics Including:
**Add here
* 10:30 - 10:45 Break
* 11:45 - 12:30 SourceForge Tickets
* 12:30 - 14:00 Lunch Break (in Meeting Room)
* 14:00 - 15:30 Afternoon Discussion Session
**Topics Including:
**Add here
* 15:30 - 15:45 Break
* 15:45 - 17:30 SourceForge Tickets

* Evening -- Possible choices include:
** "Bamboo", Korean restaurant, photos of menu at https://plus.google.com/photos/105468124820294977561/albums/5940634552368529473 Has some veggie dishes, but not loads.
** "Sojo", Szechuan/Shanghainese/Cantonese restaurant, website at http://www.sojooxford.co.uk/ claims vegetarian menu on request.
** "Bangkok House", Thai restaurant, selection of vegetarian dishes, http://www.bangkokhouse.co.uk/

== Tuesday 12 November 2013 ==
* 09:00 - 10:30 Morning Discussion Session
**Topics Including:
**Add here
* 10:30 - 10:45 Break
* 11:45 - 12:30 SourceForge Tickets
* 12:30 - 14:00 Lunch Break (in Dining Room)
* 14:00 - 15:30 Afternoon Discussion Session
**Topics Including:
**Add here
* 15:30 - 15:45 Break
* 15:45 - 17:30 SourceForge Tickets

* Evening: A meal chez Rahtz, 8pm directions and description to follow.

== Wednesday 13 November 2013 ==
* 09:00 - 10:30 Morning Discussion Session
** Report on Roma Specification [JC]
** From 09:30: Discussion with Torsten Schassan (via skype) about need for Object Description Chapter (see http://wiki.tei-c.org/index.php?title=Council_agenda_2013-11-OntologySIG)
* 10:30 - 10:45 Break
* 11:45 - 12:30 SourceForge Tickets
* 12:30 - 14:00 Lunch Break (in Meeting Room)
* 14:00 - 15:30 Afternoon Discussion Session
**Topics Including:
**Add here
* 15:30 - 15:45 Break
* 15:45 - 16:30 SourceForge Tickets for those not departing early

*Evening -- possible choices include:
** "Chutney's Indian Brasserie", Mostly Bangladeshi Food, Fair amount of vegetarian food, http://www.chutneysoxford.co.uk/
** "Al-Andalus Tapas Bar", Tapas, selection of vegetarian, http://www.tapasoxford.co.uk/
** "Branca", Overpriced Italian, limited vegetarian choices, http://www.branca.co.uk/
** "Pierre Victoire", French, limited vegetarian choices, http://www.pierrevictoire.co.uk/
** Some British Pub, undecided

== Agenda topics ==

* Discuss possible revisions to [http://www.tei-c.org/Activities/Council/Working/tcw22.xml#releaseSteps step-by-step instructions in release procedure]
** Should step 1 (creating P5/ReleaseNotes/readme-X.X.X.xml) happen at the same time as step 4 (freeze on commits)?
** Should we do steps 1 through 5 farther in advance so we can check that the version numbers etc. show up in the right places in files resulting from the build process?
** Immediately after a release, should we change the version number in the repository to next release number (e.g., "2.5a", with "a" for "alpha") so people won't be confused looking at the last successful build and seeing the old version number. Then immediately before a release, when we put out the call to TEI-L to look for typos, we can change the "a" to "b" (e.g., "2.5b") and then when we actually release, remove the "b".
** Should we have the date of a build be auto-generated? It will make it clearer that people are looking at something that's evolving, and it will also make it easier to diagnose the occasional case where one of the Jenkins servers stops updating.
* [https://sourceforge.net/p/tei/feature-requests/378/?page=2 proposals for <standoff>] -- have Javier join the discussion?

* i18n: how to take forward updating of the translations

* Development of Pure ODD [LB and SR]. See paper at http://tei.oucs.ox.ac.uk/Talks/2013-09-acmdoceng/rahtzburnard.pdf and the code at https://github.com/TEIC/pureodd

* Ideas on how to run an experimental TEI Hackathon [SR]

* Into the blue yonder: is it time to have a TEI P6 discussion again? [SR]

* Reaching consensus with EEBO TCP [SR] (see http://tei.oucs.ox.ac.uk/EEBO/ for summary of problem, and links to tickets)

* Report on new Roma Specification [JC]

* Report on specification and estimated cost for XPointer resolver [HC/SB]

* Report on specification and estimated cost for oXygen front end for ODD [SB/EM]

* Cheatsheets: Short best/recommended practice documents

* Text Directionality Workgroup: look at first draft of new Guidelines sections [MH]

Council agenda 2013-11

2013-10-21T21:22:45Z

Rahtz: /* Agenda topics */

== Agenda topics ==

* Discuss possible revisions to [http://www.tei-c.org/Activities/Council/Working/tcw22.xml#releaseSteps step-by-step instructions in release procedure]
** Should step 1 (creating P5/ReleaseNotes/readme-X.X.X.xml) happen at the same time as step 4 (freeze on commits)?
** Should we do steps 1 through 5 farther in advance so we can check that the version numbers etc. show up in the right places in files resulting from the build process?
** Immediately after a release, should we change the version number in the repository to next release number (e.g., "2.5a", with "a" for "alpha") so people won't be confused looking at the last successful build and seeing the old version number. Then immediately before a release, when we put out the call to TEI-L to look for typos, we can change the "a" to "b" (e.g., "2.5b") and then when we actually release, remove the "b".
** Should we have the date of a build be auto-generated? It will make it clearer that people are looking at something that's evolving, and it will also make it easier to diagnose the occasional case where one of the Jenkins servers stops updating.
* [https://sourceforge.net/p/tei/feature-requests/378/?page=2 proposals for <standoff>] -- have Javier join the discussion?

* P6 and Release structure

* Request from Ontology SIG [SR]. See paper at http://wiki.tei-c.org/index.php?title=Council_agenda_2013-11-OntologySIG

* Development of Pure ODD [LB and SR]. See paper at http://tei.oucs.ox.ac.uk/Talks/2013-09-acmdoceng/rahtzburnard.pdf and the code at https://github.com/TEIC/pureodd

* Ideas on how to run an experimental TEI Hackathon [SR]

* Into the blue yonder: is it time to have a TEI P6 discussion again? [SR]

* Reaching consensus with EEBO TCP [SR] (see http://tei.oucs.ox.ac.uk/EEBO/ for summary of problem, and links to tickets)

* Report on new Roma Specification [JC]

* Report on specification and estimated cost for XPointer resolver [HC/SB]

* Report on specification and estimated cost for oXygen front end for ODD [SB/EM]

* Cheatsheets: Short best/recommended practice documents

Council agenda 2013-11-OntologySIG

2013-10-21T21:01:22Z

Rahtz: Created page with "The Ontology SIG meeting in Rone discussed the need for an '''object description chapter'''. It is suggested that a working group be chartered by Council to through the MS descr..."

The Ontology SIG meeting in Rone discussed the need for an '''object description chapter'''.

It is suggested that a working group be chartered by Council to through the MS description chapter and re-consider its coverage,
marking all changes which are needed to extend the coverage of the chapter to include other objects such as paintings and tombstones, text bearing or not.

Based on the documented need for changes the group should either decide to make a combined chapter or write a new one.

Element sharing is an issue to be taken into consideration.

One solution is to extend the place-person etc. with objects and focus the MS description on all kinds of text bearing objects.
MS descriptions elements could also be considered be an extension of more general elements, and possibly
this needs addressing in ODD (ie how to say formally that an element is a specialisation of another).

All this needs a call for examples from the community, of course.

The need to change the MS desc chapter is expressed in the MS desc community as well.

Torsten Schassan, Sebastian Rahtz, Oyvind Eide and Lou Butnard have all expressed an interested
in being in this group, and Torsten is provisionally willing to lead it.

Council agenda 2013-11

2013-10-21T20:54:56Z

Rahtz: /* Agenda topics */

== Agenda topics ==

* Discuss possible revisions to [http://www.tei-c.org/Activities/Council/Working/tcw22.xml#releaseSteps step-by-step instructions in release procedure]
** Should step 1 (creating P5/ReleaseNotes/readme-X.X.X.xml) happen at the same time as step 4 (freeze on commits)?
** Should we do steps 1 through 5 farther in advance so we can check that the version numbers etc. show up in the right places in files resulting from the build process?
** Immediately after a release, should we change the version number in the repository to next release number (e.g., "2.5a", with "a" for "alpha") so people won't be confused looking at the last successful build and seeing the old version number. Then immediately before a release, when we put out the call to TEI-L to look for typos, we can change the "a" to "b" (e.g., "2.5b") and then when we actually release, remove the "b".
** Should we have the date of a build be auto-generated? It will make it clearer that people are looking at something that's evolving, and it will also make it easier to diagnose the occasional case where one of the Jenkins servers stops updating.
* [https://sourceforge.net/p/tei/feature-requests/378/?page=2 proposals for <standoff>] -- have Javier join the discussion?

* P6 and Release structure

* Request from Ontology SIG [SR]
See paper at
* Development of Pure ODD (heads-up for F2F) [LB]

* Reaching consensus with EEBO TCP [SR]

* Report on new Roma Specification [JC]

* Report on specification and estimated cost for XPointer resolver [HC/SB]

* Report on specification and estimated cost for oXygen front end for ODD [SB/EM]

* Cheatsheets: Short best/recommended practice documents

Council agenda 2013-10

2013-10-17T16:37:24Z

Rahtz:

Council Teleconference 2013-10-21 16:00 current Oxford time (11:00 Providence time, 08:00 Victoria time).

* Report on TEI Members’ Meeting and Board Meeting [SR]
* Update on Text Directionality work [MDH]
* Report on div liminal work [LB]
* Report on Physical Bibliography group [SB]
* Report on TEI for Libraries ways forward [KH]
* Report on new Roma Specification [JC]
* Report on specification and estimated cost for XPointer resolver [HC/SB]
* Report on specification and estimated cost for oXygen front end for ODD [SB/EM]
* Timetabling next release [JC]
* State of play on translation of Guidelines

* '''''Add your items here …'''''

* Planning for election of Chair [JC]
* Planning for face-to-face meeting in November [JC]
1 Request from Ontology SIG (heads-up for F2F) [SR]
2 Development of Pure ODD (heads-up for F2F) [LB]
3 Reaching consensus with EEBO TCP [SR]
* Planning for next conference call (2014-01?) [JC]

Council agenda 2013-10

2013-10-17T16:17:33Z

Rahtz:

Council Teleconference 2013-10-21 16:00 current Oxford time (11:00 Providence time, 08:00 Victoria time).

* Report on TEI Members’ Meeting and Board Meeting [SR]
* Update on Text Directionality work [MDH]
* Report on div liminal work [LB]
* Report on Physical Bibliography group [SB]
* Report on TEI for Libraries ways forward [KH]
* Report on new Roma Specification [JC]
* Report on specification and estimated cost for XPointer resolver [HC/SB]
* Report on specification and estimated cost for oXygen front end for ODD [SB/EM]
* Timetabling next release [JC]
* State of play on translation of Guidelines

* '''''Add your items here …'''''

* Planning for election of Chair [JC]
* Planning for face-to-face meeting in November [JC]
* Request from Ontology SIG (heads-up for F2F) [SR]
* Development of Pure ODD (heads-up for F2F) [LB]
* Planning for next conference call (2014-01?) [JC]

Tei-xsl

2013-09-08T11:11:35Z

Rahtz: /* Converting from DOCX format */

[[Category:Tools]]

[[Category:Conversion and preprocessing tools]]
[[Category:Publishing and delivery tools]]
[[Category:XSLT]]

== Synopsis ==
This is a family of XSLT 2.0 stylesheets to transform TEI XML documents
to various formats, including XHTML, LaTeX, XSL Formatting Objects,
ePub, plain text, RDF, JSON;
and to/from Word OOXML (docx) and OpenOfice (odt).
They concentrate on the core TEI
modules which are used for simple transcription and "born
digital" writing. It is important to understand that they do '''not'''
* cover ''all'' TEI elements and possible attribute values
* attempt to define a standard TEI processing or rendering model
They should not be treated as the definitive view of the TEI Consortium
about rendering TEI documents.

== Features ==

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

== System requirements ==
"The XSL FO style sheets were developed for use with PassiveTeX (http://projects.oucs.ox.ac.uk/passivetex/), a system using XSL formatting objects to render XML to PDF via LaTeX. They have not been extensively tested with the other XSL FO implementations."<ref>http://www.tei-c.org/Tools/Stylesheets/</ref>

Software dependencies:

* Saxon 9.2 or later. If using Debian or Ubuntu, you can get it from http://tei.oucs.ox.ac.uk/teideb/ .
* ant and ant-contrib. Note that as of 2011-11-30, ant-contrib is not availabe as as RedHat package.

== Source code and licensing ==
This software is dual-licensed:

1. Distributed under a Creative Commons Attribution-ShareAlike 3.0
Unported License http://creativecommons.org/licenses/by-sa/3.0/

2. http://www.opensource.org/licenses/BSD-2-Clause

== Support for TEI ==

The stylesheets render TEI XML documents to various formats, with the constraint that they do not offer an implementation of all tags,
and only support a limited range of values for the @rend attribute.

== Language(s) ==
Documentation is in English.

== Documentation ==
These two pages should be identical and therefore equally authoritative:

* http://www.tei-c.org/Tools/Stylesheets/
* http://www.tei-c.org/release/doc/tei-xsl/

Among the components of this package of stylesheets not documented are the following:

* <code>tools/oddbyexample.xsl</code> – generates a list of all the attribute values used in the directory of texts you apply it to, in the form of an [[ODD]] file, from which you can in turn generate documentation and schemas using Roma
* <code>tools/odd2nuodd.xsl</code> – switches from a traditional ODD-by-exclusion to a newer form ODD-by-inclusion

See also this guide by Laura Mandell, which contains some documentation and some videos: http://idhmc.tamu.edu/chat/xslt/modifyTEI.html
However, be aware that this covers an earlier release, and things may have changed

=== Creating a custom profile ===

To create a profile for converting to/from a format and TEI XML, create either or both as needed:

<code>profiles/$PROFILENAME/$FORMAT/to.xsl</code>

<code>profiles/$PROFILENAME/$FORMAT/from.xsl</code>

Start by copying the files in <code>profiles/default/$FORMAT/</code> and then adding your own overrides and/or additional templates. See [http://listserv.brown.edu/archives/cgi-bin/wa?A2=ind1303&L=TEI-L&F=&S=&P=99998 this brief example of additional templates].

Note that if your <code>$FORMAT</code> is docx, this directory must contain a file <code>template.docx</code> which is used to create .docx files from. See the sample in the default profile.

=== Converting from DOCX format ===

== Tech support ==
Bugs and feature requests should be made via the TEI general ticketing system on [https://sourceforge.net/projects/tei/ Sourceforge]

== User community ==

== Sample implementations ==

The package includes a number of profiles in the <code>profiles/</code> directory.

== Current version number and date of release ==

7.1.0 (2013-09-07)

== History of versions ==

Versions prior to 7.0.1 are at https://sourceforge.net/projects/tei/files/Stylesheets/ .

Later versions are on Github

== How to download or buy ==

If you use [[Oxygen]], the easiest thing to do might be to download as part of [http://code.google.com/p/oxygen-tei/ oxygen-tei], the open-source TEI framework built into <oXygen/>. Otherwise, there are three options:

=== Download zip file ===
Download the latest zip file (below all of the folders) from https://sourceforge.net/projects/tei/files/Stylesheets/ .

=== Install the Debian package ===

Install the <code>tei-xsl</code> Debian package from the [http://tei.oucs.ox.ac.uk/teideb/ list of Debian packages].

=== Get from Github ===

<code>
git clone git@github.com:TEIC/Stylesheets.git /path/to/local/directory/Stylesheets
</code>

Then, if you want to add these to <code>/usr/</code> (which you will need to do in order to use the command-line shell scripts), you can do the following:

<code>
cd /path/to/local/directory/Stylesheets/
</code>

<code>
make install
</code>

but note the following:

* You will need to run <code>make install</code> as a user with write permission to <code>/usr/</code> . So if using Ubuntu, for example, you will need to instead do <code>sudo make install</code> .

== Additional notes ==
The XSLT 1.0 version of this stylesheet family, which is no longer actively maintained, can be found on Github at https://github.com/sebastianrahtz/TEIXSL-v1.git

== Notes ==

<references/>

Tei-xsl

2013-09-08T11:10:31Z

Rahtz: /* Current version number and date of release */

[[Category:Tools]]

[[Category:Conversion and preprocessing tools]]
[[Category:Publishing and delivery tools]]
[[Category:XSLT]]

== Synopsis ==
This is a family of XSLT 2.0 stylesheets to transform TEI XML documents
to various formats, including XHTML, LaTeX, XSL Formatting Objects,
ePub, plain text, RDF, JSON;
and to/from Word OOXML (docx) and OpenOfice (odt).
They concentrate on the core TEI
modules which are used for simple transcription and "born
digital" writing. It is important to understand that they do '''not'''
* cover ''all'' TEI elements and possible attribute values
* attempt to define a standard TEI processing or rendering model
They should not be treated as the definitive view of the TEI Consortium
about rendering TEI documents.

== Features ==

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

== System requirements ==
"The XSL FO style sheets were developed for use with PassiveTeX (http://projects.oucs.ox.ac.uk/passivetex/), a system using XSL formatting objects to render XML to PDF via LaTeX. They have not been extensively tested with the other XSL FO implementations."<ref>http://www.tei-c.org/Tools/Stylesheets/</ref>

Software dependencies:

* Saxon 9.2 or later. If using Debian or Ubuntu, you can get it from http://tei.oucs.ox.ac.uk/teideb/ .
* ant and ant-contrib. Note that as of 2011-11-30, ant-contrib is not availabe as as RedHat package.

== Source code and licensing ==
This software is dual-licensed:

1. Distributed under a Creative Commons Attribution-ShareAlike 3.0
Unported License http://creativecommons.org/licenses/by-sa/3.0/

2. http://www.opensource.org/licenses/BSD-2-Clause

== Support for TEI ==

The stylesheets render TEI XML documents to various formats, with the constraint that they do not offer an implementation of all tags,
and only support a limited range of values for the @rend attribute.

== Language(s) ==
Documentation is in English.

== Documentation ==
These two pages should be identical and therefore equally authoritative:

* http://www.tei-c.org/Tools/Stylesheets/
* http://www.tei-c.org/release/doc/tei-xsl/

Among the components of this package of stylesheets not documented are the following:

* <code>tools/oddbyexample.xsl</code> – generates a list of all the attribute values used in the directory of texts you apply it to, in the form of an [[ODD]] file, from which you can in turn generate documentation and schemas using Roma
* <code>tools/odd2nuodd.xsl</code> – switches from a traditional ODD-by-exclusion to a newer form ODD-by-inclusion

See also this guide by Laura Mandell, which contains some documentation and some videos: http://idhmc.tamu.edu/chat/xslt/modifyTEI.html
However, be aware that this covers an earlier release, and things may have changed

=== Creating a custom profile ===

To create a profile for converting to/from a format and TEI XML, create either or both as needed:

<code>profiles/$PROFILENAME/$FORMAT/to.xsl</code>

<code>profiles/$PROFILENAME/$FORMAT/from.xsl</code>

Start by copying the files in <code>profiles/default/$FORMAT/</code> and then adding your own overrides and/or additional templates. See [http://listserv.brown.edu/archives/cgi-bin/wa?A2=ind1303&L=TEI-L&F=&S=&P=99998 this brief example of additional templates].

Note that if your <code>$FORMAT</code> is docx, this directory must contain a file <code>template.docx</code> which is used to create .docx files from. See the sample in the default profile.

=== Converting from DOCX format ===

Word has two kinds of styles: paragraph styles and character styles. According to Sebastian, "The basic rule of the conversion is that if named [character] styles are used, they take precedence over manual formatting." That is, if text (even a whole paragraph) has a character style applied but is also marked in Word as being italicized, the italics will not come through in the conversion separate from the character style. This is the single biggest defect in the system (according to Lou, and Ron!)

== Tech support ==
Bugs and feature requests should be made via the TEI general ticketing system on [https://sourceforge.net/projects/tei/ Sourceforge]

== User community ==

== Sample implementations ==

The package includes a number of profiles in the <code>profiles/</code> directory.

== Current version number and date of release ==

7.1.0 (2013-09-07)

== History of versions ==

Versions prior to 7.0.1 are at https://sourceforge.net/projects/tei/files/Stylesheets/ .

Later versions are on Github

== How to download or buy ==

If you use [[Oxygen]], the easiest thing to do might be to download as part of [http://code.google.com/p/oxygen-tei/ oxygen-tei], the open-source TEI framework built into <oXygen/>. Otherwise, there are three options:

=== Download zip file ===
Download the latest zip file (below all of the folders) from https://sourceforge.net/projects/tei/files/Stylesheets/ .

=== Install the Debian package ===

Install the <code>tei-xsl</code> Debian package from the [http://tei.oucs.ox.ac.uk/teideb/ list of Debian packages].

=== Get from Github ===

<code>
git clone git@github.com:TEIC/Stylesheets.git /path/to/local/directory/Stylesheets
</code>

Then, if you want to add these to <code>/usr/</code> (which you will need to do in order to use the command-line shell scripts), you can do the following:

<code>
cd /path/to/local/directory/Stylesheets/
</code>

<code>
make install
</code>

but note the following:

* You will need to run <code>make install</code> as a user with write permission to <code>/usr/</code> . So if using Ubuntu, for example, you will need to instead do <code>sudo make install</code> .

== Additional notes ==
The XSLT 1.0 version of this stylesheet family, which is no longer actively maintained, can be found on Github at https://github.com/sebastianrahtz/TEIXSL-v1.git

== Notes ==

<references/>

Tei-xsl

2013-09-08T11:10:11Z

Rahtz: /* History of versions */

[[Category:Tools]]

[[Category:Conversion and preprocessing tools]]
[[Category:Publishing and delivery tools]]
[[Category:XSLT]]

== Synopsis ==
This is a family of XSLT 2.0 stylesheets to transform TEI XML documents
to various formats, including XHTML, LaTeX, XSL Formatting Objects,
ePub, plain text, RDF, JSON;
and to/from Word OOXML (docx) and OpenOfice (odt).
They concentrate on the core TEI
modules which are used for simple transcription and "born
digital" writing. It is important to understand that they do '''not'''
* cover ''all'' TEI elements and possible attribute values
* attempt to define a standard TEI processing or rendering model
They should not be treated as the definitive view of the TEI Consortium
about rendering TEI documents.

== Features ==

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

== System requirements ==
"The XSL FO style sheets were developed for use with PassiveTeX (http://projects.oucs.ox.ac.uk/passivetex/), a system using XSL formatting objects to render XML to PDF via LaTeX. They have not been extensively tested with the other XSL FO implementations."<ref>http://www.tei-c.org/Tools/Stylesheets/</ref>

Software dependencies:

* Saxon 9.2 or later. If using Debian or Ubuntu, you can get it from http://tei.oucs.ox.ac.uk/teideb/ .
* ant and ant-contrib. Note that as of 2011-11-30, ant-contrib is not availabe as as RedHat package.

== Source code and licensing ==
This software is dual-licensed:

1. Distributed under a Creative Commons Attribution-ShareAlike 3.0
Unported License http://creativecommons.org/licenses/by-sa/3.0/

2. http://www.opensource.org/licenses/BSD-2-Clause

== Support for TEI ==

The stylesheets render TEI XML documents to various formats, with the constraint that they do not offer an implementation of all tags,
and only support a limited range of values for the @rend attribute.

== Language(s) ==
Documentation is in English.

== Documentation ==
These two pages should be identical and therefore equally authoritative:

* http://www.tei-c.org/Tools/Stylesheets/
* http://www.tei-c.org/release/doc/tei-xsl/

Among the components of this package of stylesheets not documented are the following:

* <code>tools/oddbyexample.xsl</code> – generates a list of all the attribute values used in the directory of texts you apply it to, in the form of an [[ODD]] file, from which you can in turn generate documentation and schemas using Roma
* <code>tools/odd2nuodd.xsl</code> – switches from a traditional ODD-by-exclusion to a newer form ODD-by-inclusion

See also this guide by Laura Mandell, which contains some documentation and some videos: http://idhmc.tamu.edu/chat/xslt/modifyTEI.html
However, be aware that this covers an earlier release, and things may have changed

=== Creating a custom profile ===

To create a profile for converting to/from a format and TEI XML, create either or both as needed:

<code>profiles/$PROFILENAME/$FORMAT/to.xsl</code>

<code>profiles/$PROFILENAME/$FORMAT/from.xsl</code>

Start by copying the files in <code>profiles/default/$FORMAT/</code> and then adding your own overrides and/or additional templates. See [http://listserv.brown.edu/archives/cgi-bin/wa?A2=ind1303&L=TEI-L&F=&S=&P=99998 this brief example of additional templates].

Note that if your <code>$FORMAT</code> is docx, this directory must contain a file <code>template.docx</code> which is used to create .docx files from. See the sample in the default profile.

=== Converting from DOCX format ===

Word has two kinds of styles: paragraph styles and character styles. According to Sebastian, "The basic rule of the conversion is that if named [character] styles are used, they take precedence over manual formatting." That is, if text (even a whole paragraph) has a character style applied but is also marked in Word as being italicized, the italics will not come through in the conversion separate from the character style. This is the single biggest defect in the system (according to Lou, and Ron!)

== Tech support ==
Bugs and feature requests should be made via the TEI general ticketing system on [https://sourceforge.net/projects/tei/ Sourceforge]

== User community ==

== Sample implementations ==

The package includes a number of profiles in the <code>profiles/</code> directory.

== Current version number and date of release ==

6.38 (2013-07-26)

== History of versions ==

Versions prior to 7.0.1 are at https://sourceforge.net/projects/tei/files/Stylesheets/ .

Later versions are on Github

== How to download or buy ==

If you use [[Oxygen]], the easiest thing to do might be to download as part of [http://code.google.com/p/oxygen-tei/ oxygen-tei], the open-source TEI framework built into <oXygen/>. Otherwise, there are three options:

=== Download zip file ===
Download the latest zip file (below all of the folders) from https://sourceforge.net/projects/tei/files/Stylesheets/ .

=== Install the Debian package ===

Install the <code>tei-xsl</code> Debian package from the [http://tei.oucs.ox.ac.uk/teideb/ list of Debian packages].

=== Get from Github ===

<code>
git clone git@github.com:TEIC/Stylesheets.git /path/to/local/directory/Stylesheets
</code>

Then, if you want to add these to <code>/usr/</code> (which you will need to do in order to use the command-line shell scripts), you can do the following:

<code>
cd /path/to/local/directory/Stylesheets/
</code>

<code>
make install
</code>

but note the following:

* You will need to run <code>make install</code> as a user with write permission to <code>/usr/</code> . So if using Ubuntu, for example, you will need to instead do <code>sudo make install</code> .

== Additional notes ==
The XSLT 1.0 version of this stylesheet family, which is no longer actively maintained, can be found on Github at https://github.com/sebastianrahtz/TEIXSL-v1.git

== Notes ==

<references/>

Tei-xsl

2013-09-08T11:09:18Z

Rahtz: /* Tech support */

[[Category:Tools]]

[[Category:Conversion and preprocessing tools]]
[[Category:Publishing and delivery tools]]
[[Category:XSLT]]

== Synopsis ==
This is a family of XSLT 2.0 stylesheets to transform TEI XML documents
to various formats, including XHTML, LaTeX, XSL Formatting Objects,
ePub, plain text, RDF, JSON;
and to/from Word OOXML (docx) and OpenOfice (odt).
They concentrate on the core TEI
modules which are used for simple transcription and "born
digital" writing. It is important to understand that they do '''not'''
* cover ''all'' TEI elements and possible attribute values
* attempt to define a standard TEI processing or rendering model
They should not be treated as the definitive view of the TEI Consortium
about rendering TEI documents.

== Features ==

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

== System requirements ==
"The XSL FO style sheets were developed for use with PassiveTeX (http://projects.oucs.ox.ac.uk/passivetex/), a system using XSL formatting objects to render XML to PDF via LaTeX. They have not been extensively tested with the other XSL FO implementations."<ref>http://www.tei-c.org/Tools/Stylesheets/</ref>

Software dependencies:

* Saxon 9.2 or later. If using Debian or Ubuntu, you can get it from http://tei.oucs.ox.ac.uk/teideb/ .
* ant and ant-contrib. Note that as of 2011-11-30, ant-contrib is not availabe as as RedHat package.

== Source code and licensing ==
This software is dual-licensed:

1. Distributed under a Creative Commons Attribution-ShareAlike 3.0
Unported License http://creativecommons.org/licenses/by-sa/3.0/

2. http://www.opensource.org/licenses/BSD-2-Clause

== Support for TEI ==

The stylesheets render TEI XML documents to various formats, with the constraint that they do not offer an implementation of all tags,
and only support a limited range of values for the @rend attribute.

== Language(s) ==
Documentation is in English.

== Documentation ==
These two pages should be identical and therefore equally authoritative:

* http://www.tei-c.org/Tools/Stylesheets/
* http://www.tei-c.org/release/doc/tei-xsl/

Among the components of this package of stylesheets not documented are the following:

* <code>tools/oddbyexample.xsl</code> – generates a list of all the attribute values used in the directory of texts you apply it to, in the form of an [[ODD]] file, from which you can in turn generate documentation and schemas using Roma
* <code>tools/odd2nuodd.xsl</code> – switches from a traditional ODD-by-exclusion to a newer form ODD-by-inclusion

See also this guide by Laura Mandell, which contains some documentation and some videos: http://idhmc.tamu.edu/chat/xslt/modifyTEI.html
However, be aware that this covers an earlier release, and things may have changed

=== Creating a custom profile ===

To create a profile for converting to/from a format and TEI XML, create either or both as needed:

<code>profiles/$PROFILENAME/$FORMAT/to.xsl</code>

<code>profiles/$PROFILENAME/$FORMAT/from.xsl</code>

Start by copying the files in <code>profiles/default/$FORMAT/</code> and then adding your own overrides and/or additional templates. See [http://listserv.brown.edu/archives/cgi-bin/wa?A2=ind1303&L=TEI-L&F=&S=&P=99998 this brief example of additional templates].

Note that if your <code>$FORMAT</code> is docx, this directory must contain a file <code>template.docx</code> which is used to create .docx files from. See the sample in the default profile.

=== Converting from DOCX format ===

Word has two kinds of styles: paragraph styles and character styles. According to Sebastian, "The basic rule of the conversion is that if named [character] styles are used, they take precedence over manual formatting." That is, if text (even a whole paragraph) has a character style applied but is also marked in Word as being italicized, the italics will not come through in the conversion separate from the character style. This is the single biggest defect in the system (according to Lou, and Ron!)

== Tech support ==
Bugs and feature requests should be made via the TEI general ticketing system on [https://sourceforge.net/projects/tei/ Sourceforge]

== User community ==

== Sample implementations ==

The package includes a number of profiles in the <code>profiles/</code> directory.

== Current version number and date of release ==

6.38 (2013-07-26)

== History of versions ==

Versions up to 6.38 are at https://sourceforge.net/projects/tei/files/Stylesheets/ .

== How to download or buy ==

If you use [[Oxygen]], the easiest thing to do might be to download as part of [http://code.google.com/p/oxygen-tei/ oxygen-tei], the open-source TEI framework built into <oXygen/>. Otherwise, there are three options:

=== Download zip file ===
Download the latest zip file (below all of the folders) from https://sourceforge.net/projects/tei/files/Stylesheets/ .

=== Install the Debian package ===

Install the <code>tei-xsl</code> Debian package from the [http://tei.oucs.ox.ac.uk/teideb/ list of Debian packages].

=== Get from Github ===

<code>
git clone git@github.com:TEIC/Stylesheets.git /path/to/local/directory/Stylesheets
</code>

Then, if you want to add these to <code>/usr/</code> (which you will need to do in order to use the command-line shell scripts), you can do the following:

<code>
cd /path/to/local/directory/Stylesheets/
</code>

<code>
make install
</code>

but note the following:

* You will need to run <code>make install</code> as a user with write permission to <code>/usr/</code> . So if using Ubuntu, for example, you will need to instead do <code>sudo make install</code> .

== Additional notes ==
The XSLT 1.0 version of this stylesheet family, which is no longer actively maintained, can be found on Github at https://github.com/sebastianrahtz/TEIXSL-v1.git

== Notes ==

<references/>

Tei-xsl

2013-09-08T11:04:49Z

Rahtz: /* Documentation */

[[Category:Tools]]

[[Category:Conversion and preprocessing tools]]
[[Category:Publishing and delivery tools]]
[[Category:XSLT]]

== Synopsis ==
This is a family of XSLT 2.0 stylesheets to transform TEI XML documents
to various formats, including XHTML, LaTeX, XSL Formatting Objects,
ePub, plain text, RDF, JSON;
and to/from Word OOXML (docx) and OpenOfice (odt).
They concentrate on the core TEI
modules which are used for simple transcription and "born
digital" writing. It is important to understand that they do '''not'''
* cover ''all'' TEI elements and possible attribute values
* attempt to define a standard TEI processing or rendering model
They should not be treated as the definitive view of the TEI Consortium
about rendering TEI documents.

== Features ==

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

== System requirements ==
"The XSL FO style sheets were developed for use with PassiveTeX (http://projects.oucs.ox.ac.uk/passivetex/), a system using XSL formatting objects to render XML to PDF via LaTeX. They have not been extensively tested with the other XSL FO implementations."<ref>http://www.tei-c.org/Tools/Stylesheets/</ref>

Software dependencies:

* Saxon 9.2 or later. If using Debian or Ubuntu, you can get it from http://tei.oucs.ox.ac.uk/teideb/ .
* ant and ant-contrib. Note that as of 2011-11-30, ant-contrib is not availabe as as RedHat package.

== Source code and licensing ==
This software is dual-licensed:

1. Distributed under a Creative Commons Attribution-ShareAlike 3.0
Unported License http://creativecommons.org/licenses/by-sa/3.0/

2. http://www.opensource.org/licenses/BSD-2-Clause

== Support for TEI ==

The stylesheets render TEI XML documents to various formats, with the constraint that they do not offer an implementation of all tags,
and only support a limited range of values for the @rend attribute.

== Language(s) ==
Documentation is in English.

== Documentation ==
These two pages should be identical and therefore equally authoritative:

* http://www.tei-c.org/Tools/Stylesheets/
* http://www.tei-c.org/release/doc/tei-xsl/

Among the components of this package of stylesheets not documented are the following:

* <code>tools/oddbyexample.xsl</code> – generates a list of all the attribute values used in the directory of texts you apply it to, in the form of an [[ODD]] file, from which you can in turn generate documentation and schemas using Roma
* <code>tools/odd2nuodd.xsl</code> – switches from a traditional ODD-by-exclusion to a newer form ODD-by-inclusion

See also this guide by Laura Mandell, which contains some documentation and some videos: http://idhmc.tamu.edu/chat/xslt/modifyTEI.html
However, be aware that this covers an earlier release, and things may have changed

=== Creating a custom profile ===

To create a profile for converting to/from a format and TEI XML, create either or both as needed:

<code>profiles/$PROFILENAME/$FORMAT/to.xsl</code>

<code>profiles/$PROFILENAME/$FORMAT/from.xsl</code>

Start by copying the files in <code>profiles/default/$FORMAT/</code> and then adding your own overrides and/or additional templates. See [http://listserv.brown.edu/archives/cgi-bin/wa?A2=ind1303&L=TEI-L&F=&S=&P=99998 this brief example of additional templates].

Note that if your <code>$FORMAT</code> is docx, this directory must contain a file <code>template.docx</code> which is used to create .docx files from. See the sample in the default profile.

=== Converting from DOCX format ===

Word has two kinds of styles: paragraph styles and character styles. According to Sebastian, "The basic rule of the conversion is that if named [character] styles are used, they take precedence over manual formatting." That is, if text (even a whole paragraph) has a character style applied but is also marked in Word as being italicized, the italics will not come through in the conversion separate from the character style. This is the single biggest defect in the system (according to Lou, and Ron!)

== Tech support ==

== User community ==

== Sample implementations ==

The package includes a number of profiles in the <code>profiles/</code> directory.

== Current version number and date of release ==

6.38 (2013-07-26)

== History of versions ==

Versions up to 6.38 are at https://sourceforge.net/projects/tei/files/Stylesheets/ .

== How to download or buy ==

If you use [[Oxygen]], the easiest thing to do might be to download as part of [http://code.google.com/p/oxygen-tei/ oxygen-tei], the open-source TEI framework built into <oXygen/>. Otherwise, there are three options:

=== Download zip file ===
Download the latest zip file (below all of the folders) from https://sourceforge.net/projects/tei/files/Stylesheets/ .

=== Install the Debian package ===

Install the <code>tei-xsl</code> Debian package from the [http://tei.oucs.ox.ac.uk/teideb/ list of Debian packages].

=== Get from Github ===

<code>
git clone git@github.com:TEIC/Stylesheets.git /path/to/local/directory/Stylesheets
</code>

Then, if you want to add these to <code>/usr/</code> (which you will need to do in order to use the command-line shell scripts), you can do the following:

<code>
cd /path/to/local/directory/Stylesheets/
</code>

<code>
make install
</code>

but note the following:

* You will need to run <code>make install</code> as a user with write permission to <code>/usr/</code> . So if using Ubuntu, for example, you will need to instead do <code>sudo make install</code> .

== Additional notes ==
The XSLT 1.0 version of this stylesheet family, which is no longer actively maintained, can be found on Github at https://github.com/sebastianrahtz/TEIXSL-v1.git

== Notes ==

<references/>

Tei-xsl

2013-09-08T11:02:41Z

Rahtz: /* Support for TEI */

[[Category:Tools]]

[[Category:Conversion and preprocessing tools]]
[[Category:Publishing and delivery tools]]
[[Category:XSLT]]

== Synopsis ==
This is a family of XSLT 2.0 stylesheets to transform TEI XML documents
to various formats, including XHTML, LaTeX, XSL Formatting Objects,
ePub, plain text, RDF, JSON;
and to/from Word OOXML (docx) and OpenOfice (odt).
They concentrate on the core TEI
modules which are used for simple transcription and "born
digital" writing. It is important to understand that they do '''not'''
* cover ''all'' TEI elements and possible attribute values
* attempt to define a standard TEI processing or rendering model
They should not be treated as the definitive view of the TEI Consortium
about rendering TEI documents.

== Features ==

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

== System requirements ==
"The XSL FO style sheets were developed for use with PassiveTeX (http://projects.oucs.ox.ac.uk/passivetex/), a system using XSL formatting objects to render XML to PDF via LaTeX. They have not been extensively tested with the other XSL FO implementations."<ref>http://www.tei-c.org/Tools/Stylesheets/</ref>

Software dependencies:

* Saxon 9.2 or later. If using Debian or Ubuntu, you can get it from http://tei.oucs.ox.ac.uk/teideb/ .
* ant and ant-contrib. Note that as of 2011-11-30, ant-contrib is not availabe as as RedHat package.

== Source code and licensing ==
This software is dual-licensed:

1. Distributed under a Creative Commons Attribution-ShareAlike 3.0
Unported License http://creativecommons.org/licenses/by-sa/3.0/

2. http://www.opensource.org/licenses/BSD-2-Clause

== Support for TEI ==

The stylesheets render TEI XML documents to various formats, with the constraint that they do not offer an implementation of all tags,
and only support a limited range of values for the @rend attribute.

== Language(s) ==
Documentation is in English.

== Documentation ==
These two pages should be identical and therefore equally authoritative:

* http://www.tei-c.org/Tools/Stylesheets/
* http://www.tei-c.org/release/doc/tei-xsl-common/

Among the components of this package of stylesheets not documented are the following:

* <code>tools/oddbyexample.xsl</code> – generates a list of all the attribute values used in the directory of texts you apply it to, in the form of an [[ODD]] file, from which you can in turn generate documentation and schemas using Roma
* <code>tools/odd2nuodd.xsl</code> – switches from a traditional ODD-by-exclusion to a newer form ODD-by-inclusion

See also this guide by Lauara Mandell, which contains some documentation and some videos: http://idhmc.tamu.edu/chat/xslt/modifyTEI.html

=== Creating a custom profile ===

To create a profile for converting to/from a format and TEI XML, create either or both as needed:

<code>profiles/$PROFILENAME/$FORMAT/to.xsl</code>

<code>profiles/$PROFILENAME/$FORMAT/from.xsl</code>

Start by copying the files in <code>profiles/default/$FORMAT/</code> and then adding your own overrides and/or additional templates. See [http://listserv.brown.edu/archives/cgi-bin/wa?A2=ind1303&L=TEI-L&F=&S=&P=99998 this brief example of additional templates].

Note that if your <code>$FORMAT</code> is docx, this directory must contain a file <code>template.docx</code> which is used to create .docx files from. See the sample in the default profile.

=== Converting from DOCX format ===

Word has two kinds of styles: paragraph styles and character styles. According to Sebastian, "The basic rule of the conversion is that if named [character] styles are used, they take precedence over manual formatting." That is, if text (even a whole paragraph) has a character style applied but is also marked in Word as being italicized, the italics will not come through in the conversion separate from the character style. This is the single biggest defect in the system (according to Lou, and Ron!)

== Tech support ==

== User community ==

== Sample implementations ==

The package includes a number of profiles in the <code>profiles/</code> directory.

== Current version number and date of release ==

6.38 (2013-07-26)

== History of versions ==

Versions up to 6.38 are at https://sourceforge.net/projects/tei/files/Stylesheets/ .

== How to download or buy ==

If you use [[Oxygen]], the easiest thing to do might be to download as part of [http://code.google.com/p/oxygen-tei/ oxygen-tei], the open-source TEI framework built into <oXygen/>. Otherwise, there are three options:

=== Download zip file ===
Download the latest zip file (below all of the folders) from https://sourceforge.net/projects/tei/files/Stylesheets/ .

=== Install the Debian package ===

Install the <code>tei-xsl</code> Debian package from the [http://tei.oucs.ox.ac.uk/teideb/ list of Debian packages].

=== Get from Github ===

<code>
git clone git@github.com:TEIC/Stylesheets.git /path/to/local/directory/Stylesheets
</code>

Then, if you want to add these to <code>/usr/</code> (which you will need to do in order to use the command-line shell scripts), you can do the following:

<code>
cd /path/to/local/directory/Stylesheets/
</code>

<code>
make install
</code>

but note the following:

* You will need to run <code>make install</code> as a user with write permission to <code>/usr/</code> . So if using Ubuntu, for example, you will need to instead do <code>sudo make install</code> .

== Additional notes ==
The XSLT 1.0 version of this stylesheet family, which is no longer actively maintained, can be found on Github at https://github.com/sebastianrahtz/TEIXSL-v1.git

== Notes ==

<references/>

Tei-xsl

2013-09-08T11:01:16Z

Rahtz: /* Source code and licensing */

[[Category:Tools]]

[[Category:Conversion and preprocessing tools]]
[[Category:Publishing and delivery tools]]
[[Category:XSLT]]

== Synopsis ==
This is a family of XSLT 2.0 stylesheets to transform TEI XML documents
to various formats, including XHTML, LaTeX, XSL Formatting Objects,
ePub, plain text, RDF, JSON;
and to/from Word OOXML (docx) and OpenOfice (odt).
They concentrate on the core TEI
modules which are used for simple transcription and "born
digital" writing. It is important to understand that they do '''not'''
* cover ''all'' TEI elements and possible attribute values
* attempt to define a standard TEI processing or rendering model
They should not be treated as the definitive view of the TEI Consortium
about rendering TEI documents.

== Features ==

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

== System requirements ==
"The XSL FO style sheets were developed for use with PassiveTeX (http://projects.oucs.ox.ac.uk/passivetex/), a system using XSL formatting objects to render XML to PDF via LaTeX. They have not been extensively tested with the other XSL FO implementations."<ref>http://www.tei-c.org/Tools/Stylesheets/</ref>

Software dependencies:

* Saxon 9.2 or later. If using Debian or Ubuntu, you can get it from http://tei.oucs.ox.ac.uk/teideb/ .
* ant and ant-contrib. Note that as of 2011-11-30, ant-contrib is not availabe as as RedHat package.

== Source code and licensing ==
This software is dual-licensed:

1. Distributed under a Creative Commons Attribution-ShareAlike 3.0
Unported License http://creativecommons.org/licenses/by-sa/3.0/

2. http://www.opensource.org/licenses/BSD-2-Clause

== Support for TEI ==

== Language(s) ==
Documentation is in English.

== Documentation ==
These two pages should be identical and therefore equally authoritative:

* http://www.tei-c.org/Tools/Stylesheets/
* http://www.tei-c.org/release/doc/tei-xsl-common/

Among the components of this package of stylesheets not documented are the following:

* <code>tools/oddbyexample.xsl</code> – generates a list of all the attribute values used in the directory of texts you apply it to, in the form of an [[ODD]] file, from which you can in turn generate documentation and schemas using Roma
* <code>tools/odd2nuodd.xsl</code> – switches from a traditional ODD-by-exclusion to a newer form ODD-by-inclusion

See also this guide by Lauara Mandell, which contains some documentation and some videos: http://idhmc.tamu.edu/chat/xslt/modifyTEI.html

=== Creating a custom profile ===

To create a profile for converting to/from a format and TEI XML, create either or both as needed:

<code>profiles/$PROFILENAME/$FORMAT/to.xsl</code>

<code>profiles/$PROFILENAME/$FORMAT/from.xsl</code>

Start by copying the files in <code>profiles/default/$FORMAT/</code> and then adding your own overrides and/or additional templates. See [http://listserv.brown.edu/archives/cgi-bin/wa?A2=ind1303&L=TEI-L&F=&S=&P=99998 this brief example of additional templates].

Note that if your <code>$FORMAT</code> is docx, this directory must contain a file <code>template.docx</code> which is used to create .docx files from. See the sample in the default profile.

=== Converting from DOCX format ===

Word has two kinds of styles: paragraph styles and character styles. According to Sebastian, "The basic rule of the conversion is that if named [character] styles are used, they take precedence over manual formatting." That is, if text (even a whole paragraph) has a character style applied but is also marked in Word as being italicized, the italics will not come through in the conversion separate from the character style. This is the single biggest defect in the system (according to Lou, and Ron!)

== Tech support ==

== User community ==

== Sample implementations ==

The package includes a number of profiles in the <code>profiles/</code> directory.

== Current version number and date of release ==

6.38 (2013-07-26)

== History of versions ==

Versions up to 6.38 are at https://sourceforge.net/projects/tei/files/Stylesheets/ .

== How to download or buy ==

If you use [[Oxygen]], the easiest thing to do might be to download as part of [http://code.google.com/p/oxygen-tei/ oxygen-tei], the open-source TEI framework built into <oXygen/>. Otherwise, there are three options:

=== Download zip file ===
Download the latest zip file (below all of the folders) from https://sourceforge.net/projects/tei/files/Stylesheets/ .

=== Install the Debian package ===

Install the <code>tei-xsl</code> Debian package from the [http://tei.oucs.ox.ac.uk/teideb/ list of Debian packages].

=== Get from Github ===

<code>
git clone git@github.com:TEIC/Stylesheets.git /path/to/local/directory/Stylesheets
</code>

Then, if you want to add these to <code>/usr/</code> (which you will need to do in order to use the command-line shell scripts), you can do the following:

<code>
cd /path/to/local/directory/Stylesheets/
</code>

<code>
make install
</code>

but note the following:

* You will need to run <code>make install</code> as a user with write permission to <code>/usr/</code> . So if using Ubuntu, for example, you will need to instead do <code>sudo make install</code> .

== Additional notes ==
The XSLT 1.0 version of this stylesheet family, which is no longer actively maintained, can be found on Github at https://github.com/sebastianrahtz/TEIXSL-v1.git

== Notes ==

<references/>

Tei-xsl

2013-09-08T11:00:24Z

Rahtz: /* Synopsis */

[[Category:Tools]]

[[Category:Conversion and preprocessing tools]]
[[Category:Publishing and delivery tools]]
[[Category:XSLT]]

== Synopsis ==
This is a family of XSLT 2.0 stylesheets to transform TEI XML documents
to various formats, including XHTML, LaTeX, XSL Formatting Objects,
ePub, plain text, RDF, JSON;
and to/from Word OOXML (docx) and OpenOfice (odt).
They concentrate on the core TEI
modules which are used for simple transcription and "born
digital" writing. It is important to understand that they do '''not'''
* cover ''all'' TEI elements and possible attribute values
* attempt to define a standard TEI processing or rendering model
They should not be treated as the definitive view of the TEI Consortium
about rendering TEI documents.

== Features ==

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

== System requirements ==
"The XSL FO style sheets were developed for use with PassiveTeX (http://projects.oucs.ox.ac.uk/passivetex/), a system using XSL formatting objects to render XML to PDF via LaTeX. They have not been extensively tested with the other XSL FO implementations."<ref>http://www.tei-c.org/Tools/Stylesheets/</ref>

Software dependencies:

* Saxon 9.2 or later. If using Debian or Ubuntu, you can get it from http://tei.oucs.ox.ac.uk/teideb/ .
* ant and ant-contrib. Note that as of 2011-11-30, ant-contrib is not availabe as as RedHat package.

== Source code and licensing ==
Freely available.

== Support for TEI ==

== Language(s) ==
Documentation is in English.

== Documentation ==
These two pages should be identical and therefore equally authoritative:

* http://www.tei-c.org/Tools/Stylesheets/
* http://www.tei-c.org/release/doc/tei-xsl-common/

Among the components of this package of stylesheets not documented are the following:

* <code>tools/oddbyexample.xsl</code> – generates a list of all the attribute values used in the directory of texts you apply it to, in the form of an [[ODD]] file, from which you can in turn generate documentation and schemas using Roma
* <code>tools/odd2nuodd.xsl</code> – switches from a traditional ODD-by-exclusion to a newer form ODD-by-inclusion

See also this guide by Lauara Mandell, which contains some documentation and some videos: http://idhmc.tamu.edu/chat/xslt/modifyTEI.html

=== Creating a custom profile ===

To create a profile for converting to/from a format and TEI XML, create either or both as needed:

<code>profiles/$PROFILENAME/$FORMAT/to.xsl</code>

<code>profiles/$PROFILENAME/$FORMAT/from.xsl</code>

Start by copying the files in <code>profiles/default/$FORMAT/</code> and then adding your own overrides and/or additional templates. See [http://listserv.brown.edu/archives/cgi-bin/wa?A2=ind1303&L=TEI-L&F=&S=&P=99998 this brief example of additional templates].

Note that if your <code>$FORMAT</code> is docx, this directory must contain a file <code>template.docx</code> which is used to create .docx files from. See the sample in the default profile.

=== Converting from DOCX format ===

Word has two kinds of styles: paragraph styles and character styles. According to Sebastian, "The basic rule of the conversion is that if named [character] styles are used, they take precedence over manual formatting." That is, if text (even a whole paragraph) has a character style applied but is also marked in Word as being italicized, the italics will not come through in the conversion separate from the character style. This is the single biggest defect in the system (according to Lou, and Ron!)

== Tech support ==

== User community ==

== Sample implementations ==

The package includes a number of profiles in the <code>profiles/</code> directory.

== Current version number and date of release ==

6.38 (2013-07-26)

== History of versions ==

Versions up to 6.38 are at https://sourceforge.net/projects/tei/files/Stylesheets/ .

== How to download or buy ==

If you use [[Oxygen]], the easiest thing to do might be to download as part of [http://code.google.com/p/oxygen-tei/ oxygen-tei], the open-source TEI framework built into <oXygen/>. Otherwise, there are three options:

=== Download zip file ===
Download the latest zip file (below all of the folders) from https://sourceforge.net/projects/tei/files/Stylesheets/ .

=== Install the Debian package ===

Install the <code>tei-xsl</code> Debian package from the [http://tei.oucs.ox.ac.uk/teideb/ list of Debian packages].

=== Get from Github ===

<code>
git clone git@github.com:TEIC/Stylesheets.git /path/to/local/directory/Stylesheets
</code>

Then, if you want to add these to <code>/usr/</code> (which you will need to do in order to use the command-line shell scripts), you can do the following:

<code>
cd /path/to/local/directory/Stylesheets/
</code>

<code>
make install
</code>

but note the following:

* You will need to run <code>make install</code> as a user with write permission to <code>/usr/</code> . So if using Ubuntu, for example, you will need to instead do <code>sudo make install</code> .

== Additional notes ==
The XSLT 1.0 version of this stylesheet family, which is no longer actively maintained, can be found on Github at https://github.com/sebastianrahtz/TEIXSL-v1.git

== Notes ==

<references/>

XML Whitespace

2013-08-07T13:59:07Z

Rahtz: /* XSLT Normalization Code */

TEI has robust features for specifying space, gaps, line breaks, and related aspects of the space between text. But TEI is an XML vocabulary, and XML itself, and programs that read and process XML files, have their own ways to deal with what they call whitespace, that is, space, tab, carriage return and linefeed characters. Sometimes the standards, constraints, and conventions imposed by XML cause problems for TEI encodings and for programs that process TEI files.

This article explains interactions between TEI and XML's treatment of whitespace and concludes with recommendations for both producers of TEI encodings and authors of programs that process TEI encodings.

==Where XML Considers Whitespace to be Significant==

In XML documents, some whitespace is significant, some is not. For example, inside the brackets that mark XML elements extra whitespace is not significant. For any program processing these as pieces of XML,

<tt><title type="main"></tt>

and

<tt><title     type = "main" ></tt>

are the same. There is no significance to the extra space. By XML rules, no application that processes the data in this XML file (processing it as XML and not just as text) is allowed to treat these two representations differently. A person or computer editing this file is free to use either one, based merely on readability and aesthetics. The fact that there is whitespace between <tt>title</tt> and <tt>type</tt> is significant, but how much or of what kind (space characters, tabs, carriage returns, new lines) is not significant. The space between <tt>type</tt> and <tt>=</tt> is not significant.

Whitespace can be significant, however, in the content of an element. For example,

<tt><name>JoAnn</name></tt>

and

<tt><name>Jo Ann</name></tt>

are different because of that space between <tt>Jo</tt> and <tt>Ann</tt>, and any program reading this element in an XML file is obliged to maintain the distinction.

But things can get complicated. Consider this:

<persName> 
 <forename>Jo</forename>
 <forename>Ann</forename>
 <surname>Henry</forename>
</persName>

Should the carriage returns and new lines matter? Should it matter if that
open area before <tt><surname></tt> is a tab or is instead four space characters? Should it matter that there is extra space after <tt><persName></tt>?

== Normalize = Collapse + Trim ==

Many applications, including web browsers and many programs that read XML files will, unless instructed otherwise, “collapse” XML whitespace, that is, they will replace any contiguous string of space characters (0x20), tabs (0x09), carriage returns (0x0D) and line feeds (0x0A) with just one space character. So

<name>Jo Ann</name>

<name>Jo Ann</name>

<name>Jo
 Ann</name>

would all be treated as if there were just one space character between <tt>Jo</tt> and <tt>Ann</tt>. Moreover many applications will remove, or “trim”, leading and trailing XML whitespace. So these, too,

<name> Jo Ann</name >

<name>
 Jo Ann</name>

<name>
 Jo 
 Ann
</name>

would be treated as if the XML had been simply <tt><name>Jo Ann</name></tt>.

Sometimes, as in the XSLT function “normalize-space()”, the term “normalize” refers to the combination of collapsing XML whitespace and then trimming. Other times, as in XML Schema, “collapse” is the name of the combined operation. This article uses the XSLT terminology: normalizing is collapsing plus trimming.

Normalizing XML whitespace is very common. It is so pervasive that it is easy to overlook that it is happening and even difficult to know which program processing an XML file is doing the normalizing—is it the XSLT processor, the XSL program, the web browser, the print routine, or some combination?

== @xml:space ==

[http://www.w3.org/TR/REC-xml/#sec-white-space The XML specification] defines an attribute, <tt>xml:space</tt>, that when set to <tt>preserve</tt> instructs applications to suspend default trimming, collapsing, and normalizing and instead keep all the spaces, tabs, carriage returns, and line feeds just as they are. If <tt>xml:space</tt> is set to default or is simply left off, no such request is made; the application is free to do whatever its developer thinks best.

The attribute <tt>xml:space</tt> is inherited by child elements. One could, for example, put <tt>xml:space="preserve"</tt> into a TEI <tt><text></tt> element but not in <tt><teiHeader></tt>, to indicate that the request applies to all of the text but to none of the header.

TEI allows <tt>xml:space</tt> to be used [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-att.global.html on any element]. But since TEI has so much rich functionality for encoding spaces, gaps, line breaks, and so on, the <tt>xml:space</tt> attribute is rarely used. Whatever could be accomplished by setting its value to <tt>preserve</tt> would be better accomplished by using native TEI elements. So the value is normally left as <tt>default</tt> by simply not including the attribute. Downstream processors are then left free to treat XML whitespace however the application developers want.

== Default Whitespace Processing ==
When <tt>xml:space</tt> is left as <tt>default</tt>, '''nothing in XML or TEI specifies how consumers of a TEI XML file should treat whitespace.'''

There are, however, unspecified conventions. TEI encodings generally assume that space will be normalized, that in this encoding

 
 We hold these truths to be self-evident, that all men are 
 are created equal, that they are endowed by their creator 
 with certain inalienable Rights, that among these are Life, 
 Liberty and the pursuit of Happiness.


some downstream processor will collapse spaces, tabs, carriage returns, and line feeds and will trim the space just after the <tt></tt> and just before the <tt></tt>, and that in this encoding, [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-persName.html from the TEI 5 Guidelines],

<persName>
 <forename>Edward</forename>
 <forename>George</forename>
 <surname type="linked">Bulwer-Lytton</surname>, <roleName>Baron Lytton of
 <placeName>Knebworth</placeName>
 </roleName>
</persName>

the man's name is <tt>Edward George Bulwer-Lytton, Baron Lytton of Knebworth</tt>, and not <tt> Edward George Bulwer-Lytton, Baron Lytton of Knebworth </tt> with space on the outsides, or <tt>EdwardGeorgeBulwer-Lytton,BaronLyttonofKnebworth</tt>, or some name with carriage returns in it.

=== Collapsing ===

A TEI encoder should assume that any string of whitespace characters will be collapsed into one space character. In theory, this can be circumvented by setting <tt>xml:space='preserve'</tt>, but not all downstream processors honor such requests. Web browsers, for example, do not. It is safer to use TEI's <tt><space></tt> element.

Programmers of downstream applications should feel free to collapse whitespace but should also honor <tt>xml:space='preserve'</tt> unless they can be certain that doing so is unnecessary.

=== Trimming ===

Whether text in an element should or will be trimmed depends on whether it is the only text in the element or it has siblings that are themselves elements.

==== Text-Only Elements ====

Even when specifications may be unclear on the matter, XML culture, conventions, product features, programming habits, and general best practices are allied not only to collapse but to trim whitespace from elements that contain only text. Encoders and consumers of TEI data should accept this. Unless <tt>@xml:space</tt> has been set to <tt>'preserve'</tt>, consumers of TEI files should trim such space and encoders should assume such space will be trimmed.

When this is done, these encodings

<country>Australia</country>

<country> Australia </country>

<country>
 Australia 
<country>

will all produce the same result. If the processing software were extracting data for use in a database, the resulting field would be <tt>country: Australia    </tt> in all three cases. If an encoder wants leading and trailing space to be preserved, if, for example,

<tt><emph rend='underline'> Yes! <emph></tt>

is meant to underline the space before and after the word, then <tt>xml:space='preserve'</tt> must be included in the <tt><emph></tt> element '''and''' it must be ensured that downstream processors actually honor <tt>xml:space='preserve'</tt>. If the underlining is meant to extend for not one but several spaces, only heroic care by encoder and consumer will ensure that it does. Use of <tt><space rend='underline'></tt> will be more reliable.

With both collapsing and trimming—that is, with normalizing—all of the following encodings would yield the same result.

<name>Ralph Waldo Emerson</name>

<name> Ralph Waldo Emerson </name>

<name>
 Ralph 
 Waldo 
 Emerson 
<name>

==== Mixed-Content Elements ====

If an element contains not just text, but other elements, where and when space should be trimmed is more complicated. Consider the following encoding.

  The <emph> cat </emph> ate  the <foreign>grande croissant</foreign>. I didn't!
 

The <tt></tt> element contains five child nodes.
{| class="wikitable"
|-
| <tt>      </tt><tt>  The </tt>
|| A text node
|-
| <tt>            </tt><tt><emph> cat </emph></tt>
|| An <tt><emph></tt> element that itself contains one text node
|-
| <tt>                              </tt><tt> ate  the </tt>
|| A text node
|-
| <tt>                                        </tt><tt><foreign>grande croissant</foreign></tt>
|| A <tt><foreign></tt> element that itself contains one text node
|-
| <tt>                                                                           . I didn't!      </tt>
|| A text node that includes a carriage return and then two spaces
|-
|}

By convention, it is presumed that this encodes a passage that could have been equivalently encoded one of these ways:

The 
<emph>cat</emph>
ate the 
<foreign>croissant</foreign>. 
I didn't!

The <emph>cat</emph> ate the <foreign>grande croissant</foreign>. I didn't!

The algorithm to normalize space in mixed content is:
* Collapse all white space, then
* trim:
** trim leading space on the first text node in an element and
** trim trailing space on the last text node in an element,
** trim both if a text node is both first and last, i.e., is the only text node in the element.

Applying that algorithm to the above passage:
{| class="wikitable"
|-
| <tt>      </tt><tt>  The </tt> 
<tt>        </tt><tt>The </tt>
|| Because this is the first node in the element, leading space is trimmed and trailing space is collapsed but not trimmed.
|-
| <tt>            </tt><tt><emph> cat </emph></tt> 
<tt>                   cat      </tt>
|| Because the only thing inside the <emph> element is a text node, the text there gets collapsed and trimmed.
|-
| <tt>                               </tt><tt> ate  the </tt> 
<tt>                               </tt><tt> ate the </tt>
|| Space is collapsed but not trimmed on either side.
|-
| <tt>                                        <foreign>grande croissant</foreign></tt> 
<tt>                                                 grande croissant</tt>

|| Space in this text-only node is collapsed and trimmed, but no change results.
|-
| <tt>                                                                         . I didn't!</tt> <tt>     </tt> 
<tt>                                                                         . I didn't!</tt>
|| Because this is the last node in the element, trailing space is trimmed and leading space is collapsed but not trimmed.
|-
|}
The result is as if the encoding had been
The <emph>cat</emph> ate the <foreign>grande croissant</foreign>. I didn't!

'''Note:''' The normalization process would have corrupted the text had the encoder put spaces ''inside'' the <emph>, like this:
The<emph> cat </emph>ate the <foreign>grande croissant</foreign>. I didn't!

The resulting text would be:

Thecatate the ''grande croissant''. I didn't!

'''An encoder should assume that an element that includes nothing but text ''will'' get trimmed.'''

== Structured Elements and xsl:strip-space ==

As mentioned above, normalization of whitespace is very common. Programmers implement it without asking encoders. And encoders presume some downstream application will effect it. This complex encoding of a person's name, [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-persName.html taken from the TEI 5 Guidelines] and mentioned above,

<persName>
 <forename>Edward</forename>
 <forename>George</forename>
 <surname type="linked">Bulwer-Lytton</surname>, <roleName>Baron Lytton of
 <placeName>Knebworth</placeName>
 </roleName>
</persName>

presumes—though without saying so—that a downstream program will normalize space according to the algorithm above and produce the name <tt>Edward George Bulwer-Lytton, Baron Lytton of Knebworth</tt>.

Note here that the <tt><persName></tt> element contains both text and elements. Note the comma. And note that had the forenames been encoded without intervening whitespace, the result would have been <tt>EdwardGeorge</tt>.

A problem lurks. Part of defining an XML vocabulary such as TEI is specifying whether an element may contain text and elements or just elements. In TEI 5, <tt><address></tt>, for example, unlike <tt><persName></tt>, may only contain other elements. This

<address>
 <street>10 Downing Street</street>
 <settlement>London</settlement>
 <postCode>SW1A 2AA</postCode>
<address>

is valid TEI. But this

<address>
 <street>10 Downing Street</street>,
 <settlement>London</settlement>
 <postCode>SW1A 2AA</postCode>
<address>

is not, because of that comma after the <tt><street></tt> element. Free non-whitespace text is not allowed between the elements that comprise the <tt><address></tt> element. Though the term is sometimes used more loosely, <tt><address></tt> would commonly be called a "structured element."

Elements that do not allow free non-whitespace text—structured elements, strictly speaking—mimic database records. When XML is used to move data between databases, such elements are the norm; indeed many XSLT programmers have never worked on anything but structured data. In a TEI file, structured data is more common in the header than in the text. A program extracting metadata from a TEI file will often be looking for structured data in the header, so that it can populate database fields, maybe like this:

street: 10 Downing Street 
settlement: London 
postCode: SW1A 2AA 

Defining an element as a structured element specifies that space between child elements can be completely ignored. Thus these two encodings

<address>
 <settlement type="city">London</settlement>
 <postCode>SW1A 2AA</postCode>
<address>

<address>
 <settlement type="city">London</settlement><postCode>SW1A 2AA</postCode>
<address>

are equivalent. They encode:

city: London 
postCode: SW1A 2AA 

Nothing in the encoding indicates that there should be a space, a comma, a new-line, or anything else between "London" and "SW1A 2AA". What, if anything, will be there is left to the processing application. When rendering prose, the application might insert a comma; when printing a mailing label, it might insert a new-line. If might use different punctuation when mailing to different countries.

To correctly process structured elements, XSL programmers insert an instruction, <tt><xsl:strip-space></tt>, at the beginning of their programs, followed by a list of the names of the structured elements. Among other things, this ensures that all whitespace between the children of structured elements will be removed. It will be as if such whitespace was collapsed and trimmed and made to completely disappear.

This situation can produce a temptation best resisted. An encoder may want to request that space be inserted between the components of a structured element, that, for example,

<address>
 <settlement type="city">London</settlement>
 <postCode>SW1A 2AA</postCode>
<address>

should be taken to encode "London SW1A 2AA". To implement this, the downstream processor could simply treat <tt><address></tt> as if it were not a structured element and was a mixed-content element instead. The encoder could then leave whitespace between the child elements and the regular normalization algorithm described above would collapse it and leave one space character.

The temptation is all the more seductive because (1) XML verification will not signal an error, (2) demands on the programmers of downstream applications are reduced, and (3) it is easy to succumb unknowingly. In XSLT, the programmer intentionally or inadvertently leaves <tt><xsl:strip-space></tt> off, something the programmer is happy to do since gathering the list of structured elements was inconvenient anyway, and all seems to be well.

But the better practice is indeed to burden the application with properly formatting structured elements. This burden is part of what it means for an element to be structured. If the project team agrees that whitespace in structured elements will be significant, the schema should be customized to make these elements mixed-content elements instead of structured elements. This ensures that future users of the XML files will be able to understand the files' contents. It also signals that

<tt><settlement>New</settlement><settlement>York</settlement></tt>

and

<tt><settlement>New</settlement> <settlement>York</settlement></tt>

are different, which they would not be if the element were a structured one.

== Recommendations ==

* Programmers should, unless instructed otherwise by <tt>@xml:space='preserve'</tt>, implement code that normalizes space.
* Encoders should presume such normalization will be done but should include a note in <tt><encodingDesc></tt> announcing the presumption. If normalization is not desired as the default, this certainly should be announced in <tt><encodingDesc></tt>
* Encoders should use <tt>xml:space='preserve'</tt> only with the utmost care. Whatever could be accomplished by using it is usually accomplished with less risk by using native TEI elements.
* Project teams should not intentionally or inadvertently use structured elements as if they were mixed-content elements. If this must be done, the schema should be customized to record the change.

== XSLT Normalization Code ==

To normalize mixed-content elements, XSLT's <tt>normalize-space()</tt> function cannot simply be used on all text nodes. The XSLT stylesheet must consider where a text node is among its siblings.

The following XSLT 1.0 code implements the normalization algorithm described above. It works for both text-only and mixed-content elements. The code overrides the built-in template for the appropriate text nodes so may simply be added to XSLT stylesheets.
<pre>

<xsl:template match="text()[not(ancestor::*[@xml:space][1]/@xml:space='preserve')]">

<xsl:if test="position()!=1 and normalize-space(substring(., 1, 1)) = '' and normalize-space()!=''">
<xsl:text> </xsl:text>
</xsl:if>
<xsl:value-of select="normalize-space()"/>

<xsl:if test="position()!=last() and position()!=1 and normalize-space(substring(., string-length())) = ''
or position()!=last() and position() =1 and normalize-space(substring(., string-length())) = '' and normalize-space()!=''
or last()=1 and string-length()!=0 and normalize-space()='' ">
<xsl:text> </xsl:text>
</xsl:if>
</xsl:template>
</pre>
The <tt>normalize-space(substring(., string-length())) = <nowiki>''</nowiki></tt> is just a way to test for whitespace.

An alternative in XSLT 2.0 is the code below, which covers all uses of <tt>text()</tt>. it is written in a slightly more verbose style than the XSLT 1.0 version.

<pre>
<xsl:template match="text()">
<xsl:choose>
<xsl:when
test="ancestor::*[@xml:space][1]/@xml:space='preserve'">
<xsl:value-of select="."/>
</xsl:when>
<xsl:otherwise>

<xsl:if test="position()!=1 and
matches(.,'^\s') and
normalize-space()!=''">
<xsl:text> </xsl:text>
</xsl:if>
<xsl:value-of select="."/>
<xsl:choose>

<xsl:when test="last()=1 and string-length()!=0 and normalize-space()=''">
<xsl:text> </xsl:text>
</xsl:when>

<xsl:when test="position()!=1 and position()!=last() and matches(.,'\s$')">
<xsl:text> </xsl:text>
</xsl:when>

<xsl:when test="position()=1 and matches(.,'\s$') and normalize-space()!=''">
<xsl:text> </xsl:text>
</xsl:when>
</xsl:choose>
</xsl:otherwise>
</xsl:choose>
</xsl:template>
</pre>

Under some circumstances this code will give the wrong result, as the result of <tt>position()</tt> applied to <tt>text()</tt> does not always return the right answer for this use. A more
foolproof method is
<pre>
<xsl:template match="text()">
<xsl:variable name="first" select="if (preceding-sibling::text()) then false() else true() "/>
<xsl:variable name="more" select="if (following-sibling::text()) then false() else true() "/>
<xsl:choose>
<xsl:when
test="ancestor::*[@xml:space][1]/@xml:space='preserve'">
<xsl:value-of select="."/>
</xsl:when>
<xsl:otherwise>

<xsl:if test="not($first) and
matches(.,'^\s') and
normalize-space()!=''">
<xsl:text> </xsl:text>
</xsl:if>
<xsl:value-of select="normalize-space(.)"/>
<xsl:choose>

<xsl:when test="$first and not ($more) and
string-length()!=0 and
normalize-space()=''">
<xsl:text> </xsl:text>
</xsl:when>

<xsl:when test="not($first) and $more and matches(.,'\s$')">
<xsl:text> </xsl:text>
</xsl:when>

<xsl:when test="$first and $more and matches(.,'\s$') and
normalize-space()!=''">
<xsl:text> </xsl:text>
</xsl:when>
</xsl:choose>
</xsl:otherwise>
</xsl:choose>
</xsl:template>
</pre>

== External Links ==
*[http://www.w3.org/TR/REC-xml/#sec-white-space XML 1.0 (Fifth Edition W3C Recommendation 26 November 2008) 2.10 White Space Handling] The spec on @xml:space.
*[http://www.jenitennison.com/blog/node/41 Things that make me scream: xml:space="preserve" in WordML] Frustrations of dealing with @xml:space.
*[http://lists.xml.org/archives/xml-dev/201207/msg00172.html What is @xml:space about?] A discussion of @xml:space on xml-dev.
*[http://msdn.microsoft.com/en-us/library/ms788746(v=vs.90).aspx Whitespace Processing in XAML] Another description of the algorithm for normalizing mixed-content elements.

[[Category:XSLT]]
[[Category:Markup]]
[[Category:Recommended Practice]]

XML Whitespace

2013-08-07T10:28:59Z

Rahtz: /* XSLT Normalization Code */

TEI has robust features for specifying space, gaps, line breaks, and related aspects of the space between text. But TEI is an XML vocabulary, and XML itself, and programs that read and process XML files, have their own ways to deal with what they call whitespace, that is, space, tab, carriage return and linefeed characters. Sometimes the standards, constraints, and conventions imposed by XML cause problems for TEI encodings and for programs that process TEI files.

This article explains interactions between TEI and XML's treatment of whitespace and concludes with recommendations for both producers of TEI encodings and authors of programs that process TEI encodings.

==Where XML Considers Whitespace to be Significant==

In XML documents, some whitespace is significant, some is not. For example, inside the brackets that mark XML elements extra whitespace is not significant. For any program processing these as pieces of XML,

<tt><title type="main"></tt>

and

<tt><title     type = "main" ></tt>

are the same. There is no significance to the extra space. By XML rules, no application that processes the data in this XML file (processing it as XML and not just as text) is allowed to treat these two representations differently. A person or computer editing this file is free to use either one, based merely on readability and aesthetics. The fact that there is whitespace between <tt>title</tt> and <tt>type</tt> is significant, but how much or of what kind (space characters, tabs, carriage returns, new lines) is not significant. The space between <tt>type</tt> and <tt>=</tt> is not significant.

Whitespace can be significant, however, in the content of an element. For example,

<tt><name>JoAnn</name></tt>

and

<tt><name>Jo Ann</name></tt>

are different because of that space between <tt>Jo</tt> and <tt>Ann</tt>, and any program reading this element in an XML file is obliged to maintain the distinction.

But things can get complicated. Consider this:

<persName> 
 <forename>Jo</forename>
 <forename>Ann</forename>
 <surname>Henry</forename>
</persName>

Should the carriage returns and new lines matter? Should it matter if that
open area before <tt><surname></tt> is a tab or is instead four space characters? Should it matter that there is extra space after <tt><persName></tt>?

== Normalize = Collapse + Trim ==

Many applications, including web browsers and many programs that read XML files will, unless instructed otherwise, “collapse” XML whitespace, that is, they will replace any contiguous string of space characters (0x20), tabs (0x09), carriage returns (0x0D) and line feeds (0x0A) with just one space character. So

<name>Jo Ann</name>

<name>Jo Ann</name>

<name>Jo
 Ann</name>

would all be treated as if there were just one space character between <tt>Jo</tt> and <tt>Ann</tt>. Moreover many applications will remove, or “trim”, leading and trailing XML whitespace. So these, too,

<name> Jo Ann</name >

<name>
 Jo Ann</name>

<name>
 Jo 
 Ann
</name>

would be treated as if the XML had been simply <tt><name>Jo Ann</name></tt>.

Sometimes, as in the XSLT function “normalize-space()”, the term “normalize” refers to the combination of collapsing XML whitespace and then trimming. Other times, as in XML Schema, “collapse” is the name of the combined operation. This article uses the XSLT terminology: normalizing is collapsing plus trimming.

Normalizing XML whitespace is very common. It is so pervasive that it is easy to overlook that it is happening and even difficult to know which program processing an XML file is doing the normalizing—is it the XSLT processor, the XSL program, the web browser, the print routine, or some combination?

== @xml:space ==

[http://www.w3.org/TR/REC-xml/#sec-white-space The XML specification] defines an attribute, <tt>xml:space</tt>, that when set to <tt>preserve</tt> instructs applications to suspend default trimming, collapsing, and normalizing and instead keep all the spaces, tabs, carriage returns, and line feeds just as they are. If <tt>xml:space</tt> is set to default or is simply left off, no such request is made; the application is free to do whatever its developer thinks best.

The attribute <tt>xml:space</tt> is inherited by child elements. One could, for example, put <tt>xml:space="preserve"</tt> into a TEI <tt><text></tt> element but not in <tt><teiHeader></tt>, to indicate that the request applies to all of the text but to none of the header.

TEI allows <tt>xml:space</tt> to be used [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-att.global.html on any element]. But since TEI has so much rich functionality for encoding spaces, gaps, line breaks, and so on, the <tt>xml:space</tt> attribute is rarely used. Whatever could be accomplished by setting its value to <tt>preserve</tt> would be better accomplished by using native TEI elements. So the value is normally left as <tt>default</tt> by simply not including the attribute. Downstream processors are then left free to treat XML whitespace however the application developers want.

== Default Whitespace Processing ==
When <tt>xml:space</tt> is left as <tt>default</tt>, '''nothing in XML or TEI specifies how consumers of a TEI XML file should treat whitespace.'''

There are, however, unspecified conventions. TEI encodings generally assume that space will be normalized, that in this encoding

 
 We hold these truths to be self-evident, that all men are 
 are created equal, that they are endowed by their creator 
 with certain inalienable Rights, that among these are Life, 
 Liberty and the pursuit of Happiness.


some downstream processor will collapse spaces, tabs, carriage returns, and line feeds and will trim the space just after the <tt></tt> and just before the <tt></tt>, and that in this encoding, [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-persName.html from the TEI 5 Guidelines],

<persName>
 <forename>Edward</forename>
 <forename>George</forename>
 <surname type="linked">Bulwer-Lytton</surname>, <roleName>Baron Lytton of
 <placeName>Knebworth</placeName>
 </roleName>
</persName>

the man's name is <tt>Edward George Bulwer-Lytton, Baron Lytton of Knebworth</tt>, and not <tt> Edward George Bulwer-Lytton, Baron Lytton of Knebworth </tt> with space on the outsides, or <tt>EdwardGeorgeBulwer-Lytton,BaronLyttonofKnebworth</tt>, or some name with carriage returns in it.

=== Collapsing ===

A TEI encoder should assume that any string of whitespace characters will be collapsed into one space character. In theory, this can be circumvented by setting <tt>xml:space='preserve'</tt>, but not all downstream processors honor such requests. Web browsers, for example, do not. It is safer to use TEI's <tt><space></tt> element.

Programmers of downstream applications should feel free to collapse whitespace but should also honor <tt>xml:space='preserve'</tt> unless they can be certain that doing so is unnecessary.

=== Trimming ===

Whether text in an element should or will be trimmed depends on whether it is the only text in the element or it has siblings that are themselves elements.

==== Text-Only Elements ====

Even when specifications may be unclear on the matter, XML culture, conventions, product features, programming habits, and general best practices are allied not only to collapse but to trim whitespace from elements that contain only text. Encoders and consumers of TEI data should accept this. Unless <tt>@xml:space</tt> has been set to <tt>'preserve'</tt>, consumers of TEI files should trim such space and encoders should assume such space will be trimmed.

When this is done, these encodings

<country>Australia</country>

<country> Australia </country>

<country>
 Australia 
<country>

will all produce the same result. If the processing software were extracting data for use in a database, the resulting field would be <tt>country: Australia    </tt> in all three cases. If an encoder wants leading and trailing space to be preserved, if, for example,

<tt><emph rend='underline'> Yes! <emph></tt>

is meant to underline the space before and after the word, then <tt>xml:space='preserve'</tt> must be included in the <tt><emph></tt> element '''and''' it must be ensured that downstream processors actually honor <tt>xml:space='preserve'</tt>. If the underlining is meant to extend for not one but several spaces, only heroic care by encoder and consumer will ensure that it does. Use of <tt><space rend='underline'></tt> will be more reliable.

With both collapsing and trimming—that is, with normalizing—all of the following encodings would yield the same result.

<name>Ralph Waldo Emerson</name>

<name> Ralph Waldo Emerson </name>

<name>
 Ralph 
 Waldo 
 Emerson 
<name>

==== Mixed-Content Elements ====

If an element contains not just text, but other elements, where and when space should be trimmed is more complicated. Consider the following encoding.

  The <emph> cat </emph> ate  the <foreign>grande croissant</foreign>. I didn't!
 

The <tt></tt> element contains five child nodes.
{| class="wikitable"
|-
| <tt>      </tt><tt>  The </tt>
|| A text node
|-
| <tt>            </tt><tt><emph> cat </emph></tt>
|| An <tt><emph></tt> element that itself contains one text node
|-
| <tt>                              </tt><tt> ate  the </tt>
|| A text node
|-
| <tt>                                        </tt><tt><foreign>grande croissant</foreign></tt>
|| A <tt><foreign></tt> element that itself contains one text node
|-
| <tt>                                                                           . I didn't!      </tt>
|| A text node that includes a carriage return and then two spaces
|-
|}

By convention, it is presumed that this encodes a passage that could have been equivalently encoded one of these ways:

The 
<emph>cat</emph>
ate the 
<foreign>croissant</foreign>. 
I didn't!

The <emph>cat</emph> ate the <foreign>grande croissant</foreign>. I didn't!

The algorithm to normalize space in mixed content is:
* Collapse all white space, then
* trim:
** trim leading space on the first text node in an element and
** trim trailing space on the last text node in an element,
** trim both if a text node is both first and last, i.e., is the only text node in the element.

Applying that algorithm to the above passage:
{| class="wikitable"
|-
| <tt>      </tt><tt>  The </tt> 
<tt>        </tt><tt>The </tt>
|| Because this is the first node in the element, leading space is trimmed and trailing space is collapsed but not trimmed.
|-
| <tt>            </tt><tt><emph> cat </emph></tt> 
<tt>                   cat      </tt>
|| Because the only thing inside the <emph> element is a text node, the text there gets collapsed and trimmed.
|-
| <tt>                               </tt><tt> ate  the </tt> 
<tt>                               </tt><tt> ate the </tt>
|| Space is collapsed but not trimmed on either side.
|-
| <tt>                                        <foreign>grande croissant</foreign></tt> 
<tt>                                                 grande croissant</tt>

|| Space in this text-only node is collapsed and trimmed, but no change results.
|-
| <tt>                                                                         . I didn't!</tt> <tt>     </tt> 
<tt>                                                                         . I didn't!</tt>
|| Because this is the last node in the element, trailing space is trimmed and leading space is collapsed but not trimmed.
|-
|}
The result is as if the encoding had been
The <emph>cat</emph> ate the <foreign>grande croissant</foreign>. I didn't!

'''Note:''' The normalization process would have corrupted the text had the encoder put spaces ''inside'' the <emph>, like this:
The<emph> cat </emph>ate the <foreign>grande croissant</foreign>. I didn't!

The resulting text would be:

Thecatate the ''grande croissant''. I didn't!

'''An encoder should assume that an element that includes nothing but text ''will'' get trimmed.'''

== Structured Elements and xsl:strip-space ==

As mentioned above, normalization of whitespace is very common. Programmers implement it without asking encoders. And encoders presume some downstream application will effect it. This complex encoding of a person's name, [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-persName.html taken from the TEI 5 Guidelines] and mentioned above,

<persName>
 <forename>Edward</forename>
 <forename>George</forename>
 <surname type="linked">Bulwer-Lytton</surname>, <roleName>Baron Lytton of
 <placeName>Knebworth</placeName>
 </roleName>
</persName>

presumes—though without saying so—that a downstream program will normalize space according to the algorithm above and produce the name <tt>Edward George Bulwer-Lytton, Baron Lytton of Knebworth</tt>.

Note here that the <tt><persName></tt> element contains both text and elements. Note the comma. And note that had the forenames been encoded without intervening whitespace, the result would have been <tt>EdwardGeorge</tt>.

A problem lurks. Part of defining an XML vocabulary such as TEI is specifying whether an element may contain text and elements or just elements. In TEI 5, <tt><address></tt>, for example, unlike <tt><persName></tt>, may only contain other elements. This

<address>
 <street>10 Downing Street</street>
 <settlement>London</settlement>
 <postCode>SW1A 2AA</postCode>
<address>

is valid TEI. But this

<address>
 <street>10 Downing Street</street>,
 <settlement>London</settlement>
 <postCode>SW1A 2AA</postCode>
<address>

is not, because of that comma after the <tt><street></tt> element. Free non-whitespace text is not allowed between the elements that comprise the <tt><address></tt> element. Though the term is sometimes used more loosely, <tt><address></tt> would commonly be called a "structured element."

Elements that do not allow free non-whitespace text—structured elements, strictly speaking—mimic database records. When XML is used to move data between databases, such elements are the norm; indeed many XSLT programmers have never worked on anything but structured data. In a TEI file, structured data is more common in the header than in the text. A program extracting metadata from a TEI file will often be looking for structured data in the header, so that it can populate database fields, maybe like this:

street: 10 Downing Street 
settlement: London 
postCode: SW1A 2AA 

Defining an element as a structured element specifies that space between child elements can be completely ignored. Thus these two encodings

<address>
 <settlement type="city">London</settlement>
 <postCode>SW1A 2AA</postCode>
<address>

<address>
 <settlement type="city">London</settlement><postCode>SW1A 2AA</postCode>
<address>

are equivalent. They encode:

city: London 
postCode: SW1A 2AA 

Nothing in the encoding indicates that there should be a space, a comma, a new-line, or anything else between "London" and "SW1A 2AA". What, if anything, will be there is left to the processing application. When rendering prose, the application might insert a comma; when printing a mailing label, it might insert a new-line. If might use different punctuation when mailing to different countries.

To correctly process structured elements, XSL programmers insert an instruction, <tt><xsl:strip-space></tt>, at the beginning of their programs, followed by a list of the names of the structured elements. Among other things, this ensures that all whitespace between the children of structured elements will be removed. It will be as if such whitespace was collapsed and trimmed and made to completely disappear.

This situation can produce a temptation best resisted. An encoder may want to request that space be inserted between the components of a structured element, that, for example,

<address>
 <settlement type="city">London</settlement>
 <postCode>SW1A 2AA</postCode>
<address>

should be taken to encode "London SW1A 2AA". To implement this, the downstream processor could simply treat <tt><address></tt> as if it were not a structured element and was a mixed-content element instead. The encoder could then leave whitespace between the child elements and the regular normalization algorithm described above would collapse it and leave one space character.

The temptation is all the more seductive because (1) XML verification will not signal an error, (2) demands on the programmers of downstream applications are reduced, and (3) it is easy to succumb unknowingly. In XSLT, the programmer intentionally or inadvertently leaves <tt><xsl:strip-space></tt> off, something the programmer is happy to do since gathering the list of structured elements was inconvenient anyway, and all seems to be well.

But the better practice is indeed to burden the application with properly formatting structured elements. This burden is part of what it means for an element to be structured. If the project team agrees that whitespace in structured elements will be significant, the schema should be customized to make these elements mixed-content elements instead of structured elements. This ensures that future users of the XML files will be able to understand the files' contents. It also signals that

<tt><settlement>New</settlement><settlement>York</settlement></tt>

and

<tt><settlement>New</settlement> <settlement>York</settlement></tt>

are different, which they would not be if the element were a structured one.

== Recommendations ==

* Programmers should, unless instructed otherwise by <tt>@xml:space='preserve'</tt>, implement code that normalizes space.
* Encoders should presume such normalization will be done but should include a note in <tt><encodingDesc></tt> announcing the presumption. If normalization is not desired as the default, this certainly should be announced in <tt><encodingDesc></tt>
* Encoders should use <tt>xml:space='preserve'</tt> only with the utmost care. Whatever could be accomplished by using it is usually accomplished with less risk by using native TEI elements.
* Project teams should not intentionally or inadvertently use structured elements as if they were mixed-content elements. If this must be done, the schema should be customized to record the change.

== XSLT Normalization Code ==

To normalize mixed-content elements, XSLT's <tt>normalize-space()</tt> function cannot simply be used on all text nodes. The XSLT stylesheet must consider where a text node is among its siblings.

The following XSLT 1.0 code implements the normalization algorithm described above. It works for both text-only and mixed-content elements. The code overrides the built-in template for the appropriate text nodes so may simply be added to XSLT stylesheets.
<pre>

<xsl:template match="text()[not(ancestor::*[@xml:space][1]/@xml:space='preserve')]">

<xsl:if test="position()!=1 and normalize-space(substring(., 1, 1)) = '' and normalize-space()!=''">
<xsl:text> </xsl:text>
</xsl:if>
<xsl:value-of select="normalize-space()"/>

<xsl:if test="position()!=last() and position()!=1 and normalize-space(substring(., string-length())) = ''
or position()!=last() and position() =1 and normalize-space(substring(., string-length())) = '' and normalize-space()!=''
or last()=1 and string-length()!=0 and normalize-space()='' ">
<xsl:text> </xsl:text>
</xsl:if>
</xsl:template>
</pre>
The <tt>normalize-space(substring(., string-length())) = <nowiki>''</nowiki></tt> is just a way to test for whitespace.

An alternative in XSLT 2.0 is the code below, which covers all uses of <tt>text()</tt>. it is written in a slightly more verbose style than the XSLT 1.0 version.

<pre>
<xsl:template match="text()">
<xsl:choose>
<xsl:when
test="ancestor::*[@xml:space][1]/@xml:space='preserve'">
<xsl:value-of select="."/>
</xsl:when>
<xsl:otherwise>

<xsl:if test="position()!=1 and
matches(.,'^\s') and
normalize-space()!=''">
<xsl:text> </xsl:text>
</xsl:if>
<xsl:value-of select="."/>
<xsl:choose>

<xsl:when test="last()=1 and string-length()!=0 and normalize-space()=''">
<xsl:text> </xsl:text>
</xsl:when>

<xsl:when test="position()!=1 and position()!=last() and matches(.,'\s$')">
<xsl:text> </xsl:text>
</xsl:when>

<xsl:when test="position()=1 and matches(.,'\s$') and normalize-space()!=''">
<xsl:text> </xsl:text>
</xsl:when>
</xsl:choose>
</xsl:otherwise>
</xsl:choose>
</xsl:template>
</pre>

Under some circumstances this code will give the wrong result, as the result of <tt>position()</tt> applied to <tt>text()</tt> does not always return the right answer for this use. A more
foolproof method is
<pre>
<xsl:template match="text()">
<xsl:variable name="first" select="if (preceding-sibling::text()) then false() else true() "/>
<xsl:variable name="more" select="if (following-sibling::text()) then false() else true() "/>
<xsl:choose>
<xsl:when
test="ancestor::*[@xml:space][1]/@xml:space='preserve'">
<xsl:value-of select="normalize-space(.)"/>
</xsl:when>
<xsl:otherwise>

<xsl:if test="not($first) and
matches(.,'^\s') and
normalize-space()!=''">
<xsl:text> </xsl:text>
</xsl:if>
<xsl:value-of select="normalize-space(.)"/>
<xsl:choose>

<xsl:when test="$first and not ($more) and
string-length()!=0 and
normalize-space()=''">
<xsl:text> </xsl:text>
</xsl:when>

<xsl:when test="not($first) and $more and matches(.,'\s$')">
<xsl:text> </xsl:text>
</xsl:when>

<xsl:when test="$first and $more and matches(.,'\s$') and
normalize-space()!=''">
<xsl:text> </xsl:text>
</xsl:when>
</xsl:choose>
</xsl:otherwise>
</xsl:choose>
</xsl:template>
</pre>

== External Links ==
*[http://www.w3.org/TR/REC-xml/#sec-white-space XML 1.0 (Fifth Edition W3C Recommendation 26 November 2008) 2.10 White Space Handling] The spec on @xml:space.
*[http://www.jenitennison.com/blog/node/41 Things that make me scream: xml:space="preserve" in WordML] Frustrations of dealing with @xml:space.
*[http://lists.xml.org/archives/xml-dev/201207/msg00172.html What is @xml:space about?] A discussion of @xml:space on xml-dev.
*[http://msdn.microsoft.com/en-us/library/ms788746(v=vs.90).aspx Whitespace Processing in XAML] Another description of the algorithm for normalizing mixed-content elements.

[[Category:XSLT]]
[[Category:Markup]]
[[Category:Recommended Practice]]

XML Whitespace

2013-08-06T22:28:11Z

Rahtz: /* XSLT Normalization Code */

TEI has robust features for specifying space, gaps, line breaks, and related aspects of the space between text. But TEI is an XML vocabulary, and XML itself, and programs that read and process XML files, have their own ways to deal with what they call whitespace, that is, space, tab, carriage return and linefeed characters. Sometimes the standards, constraints, and conventions imposed by XML cause problems for TEI encodings and for programs that process TEI files.

This article explains interactions between TEI and XML's treatment of whitespace and concludes with recommendations for both producers of TEI encodings and authors of programs that process TEI encodings.

==Where XML Considers Whitespace to be Significant==

In XML documents, some whitespace is significant, some is not. For example, inside the brackets that mark XML elements extra whitespace is not significant. For any program processing these as pieces of XML,

<tt><title type="main"></tt>

and

<tt><title     type = "main" ></tt>

are the same. There is no significance to the extra space. By XML rules, no application that processes the data in this XML file (processing it as XML and not just as text) is allowed to treat these two representations differently. A person or computer editing this file is free to use either one, based merely on readability and aesthetics. The fact that there is whitespace between <tt>title</tt> and <tt>type</tt> is significant, but how much or of what kind (space characters, tabs, carriage returns, new lines) is not significant. The space between <tt>type</tt> and <tt>=</tt> is not significant.

Whitespace can be significant, however, in the content of an element. For example,

<tt><name>JoAnn</name></tt>

and

<tt><name>Jo Ann</name></tt>

are different because of that space between <tt>Jo</tt> and <tt>Ann</tt>, and any program reading this element in an XML file is obliged to maintain the distinction.

But things can get complicated. Consider this:

<persName> 
 <forename>Jo</forename>
 <forename>Ann</forename>
 <surname>Henry</forename>
</persName>

Should the carriage returns and new lines matter? Should it matter if that
open area before <tt><surname></tt> is a tab or is instead four space characters? Should it matter that there is extra space after <tt><persName></tt>?

== Normalize = Collapse + Trim ==

Many applications, including web browsers and many programs that read XML files will, unless instructed otherwise, “collapse” XML whitespace, that is, they will replace any contiguous string of space characters (0x20), tabs (0x09), carriage returns (0x0D) and line feeds (0x0A) with just one space character. So

<name>Jo Ann</name>

<name>Jo Ann</name>

<name>Jo
 Ann</name>

would all be treated as if there were just one space character between <tt>Jo</tt> and <tt>Ann</tt>. Moreover many applications will remove, or “trim”, leading and trailing XML whitespace. So these, too,

<name> Jo Ann</name >

<name>
 Jo Ann</name>

<name>
 Jo 
 Ann
</name>

would be treated as if the XML had been simply <tt><name>Jo Ann</name></tt>.

Sometimes, as in the XSLT function “normalize-space()”, the term “normalize” refers to the combination of collapsing XML whitespace and then trimming. Other times, as in XML Schema, “collapse” is the name of the combined operation. This article uses the XSLT terminology: normalizing is collapsing plus trimming.

Normalizing XML whitespace is very common. It is so pervasive that it is easy to overlook that it is happening and even difficult to know which program processing an XML file is doing the normalizing—is it the XSLT processor, the XSL program, the web browser, the print routine, or some combination?

== @xml:space ==

[http://www.w3.org/TR/REC-xml/#sec-white-space The XML specification] defines an attribute, <tt>xml:space</tt>, that when set to <tt>preserve</tt> instructs applications to suspend default trimming, collapsing, and normalizing and instead keep all the spaces, tabs, carriage returns, and line feeds just as they are. If <tt>xml:space</tt> is set to default or is simply left off, no such request is made; the application is free to do whatever its developer thinks best.

The attribute <tt>xml:space</tt> is inherited by child elements. One could, for example, put <tt>xml:space="preserve"</tt> into a TEI <tt><text></tt> element but not in <tt><teiHeader></tt>, to indicate that the request applies to all of the text but to none of the header.

TEI allows <tt>xml:space</tt> to be used [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-att.global.html on any element]. But since TEI has so much rich functionality for encoding spaces, gaps, line breaks, and so on, the <tt>xml:space</tt> attribute is rarely used. Whatever could be accomplished by setting its value to <tt>preserve</tt> would be better accomplished by using native TEI elements. So the value is normally left as <tt>default</tt> by simply not including the attribute. Downstream processors are then left free to treat XML whitespace however the application developers want.

== Default Whitespace Processing ==
When <tt>xml:space</tt> is left as <tt>default</tt>, '''nothing in XML or TEI specifies how consumers of a TEI XML file should treat whitespace.'''

There are, however, unspecified conventions. TEI encodings generally assume that space will be normalized, that in this encoding

 
 We hold these truths to be self-evident, that all men are 
 are created equal, that they are endowed by their creator 
 with certain inalienable Rights, that among these are Life, 
 Liberty and the pursuit of Happiness.


some downstream processor will collapse spaces, tabs, carriage returns, and line feeds and will trim the space just after the <tt></tt> and just before the <tt></tt>, and that in this encoding, [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-persName.html from the TEI 5 Guidelines],

<persName>
 <forename>Edward</forename>
 <forename>George</forename>
 <surname type="linked">Bulwer-Lytton</surname>, <roleName>Baron Lytton of
 <placeName>Knebworth</placeName>
 </roleName>
</persName>

the man's name is <tt>Edward George Bulwer-Lytton, Baron Lytton of Knebworth</tt>, and not <tt> Edward George Bulwer-Lytton, Baron Lytton of Knebworth </tt> with space on the outsides, or <tt>EdwardGeorgeBulwer-Lytton,BaronLyttonofKnebworth</tt>, or some name with carriage returns in it.

=== Collapsing ===

A TEI encoder should assume that any string of whitespace characters will be collapsed into one space character. In theory, this can be circumvented by setting <tt>xml:space='preserve'</tt>, but not all downstream processors honor such requests. Web browsers, for example, do not. It is safer to use TEI's <tt><space></tt> element.

Programmers of downstream applications should feel free to collapse whitespace but should also honor <tt>xml:space='preserve'</tt> unless they can be certain that doing so is unnecessary.

=== Trimming ===

Whether text in an element should or will be trimmed depends on whether it is the only text in the element or it has siblings that are themselves elements.

==== Text-Only Elements ====

Even when specifications may be unclear on the matter, XML culture, conventions, product features, programming habits, and general best practices are allied not only to collapse but to trim whitespace from elements that contain only text. Encoders and consumers of TEI data should accept this. Unless <tt>@xml:space</tt> has been set to <tt>'preserve'</tt>, consumers of TEI files should trim such space and encoders should assume such space will be trimmed.

When this is done, these encodings

<country>Australia</country>

<country> Australia </country>

<country>
 Australia 
<country>

will all produce the same result. If the processing software were extracting data for use in a database, the resulting field would be <tt>country: Australia    </tt> in all three cases. If an encoder wants leading and trailing space to be preserved, if, for example,

<tt><emph rend='underline'> Yes! <emph></tt>

is meant to underline the space before and after the word, then <tt>xml:space='preserve'</tt> must be included in the <tt><emph></tt> element '''and''' it must be ensured that downstream processors actually honor <tt>xml:space='preserve'</tt>. If the underlining is meant to extend for not one but several spaces, only heroic care by encoder and consumer will ensure that it does. Use of <tt><space rend='underline'></tt> will be more reliable.

With both collapsing and trimming—that is, with normalizing—all of the following encodings would yield the same result.

<name>Ralph Waldo Emerson</name>

<name> Ralph Waldo Emerson </name>

<name>
 Ralph 
 Waldo 
 Emerson 
<name>

==== Mixed-Content Elements ====

If an element contains not just text, but other elements, where and when space should be trimmed is more complicated. Consider the following encoding.

  The <emph> cat </emph> ate  the <foreign>grande croissant</foreign>. I didn't!
 

The <tt></tt> element contains five child nodes.
{| class="wikitable"
|-
| <tt>      </tt><tt>  The </tt>
|| A text node
|-
| <tt>            </tt><tt><emph> cat </emph></tt>
|| An <tt><emph></tt> element that itself contains one text node
|-
| <tt>                              </tt><tt> ate  the </tt>
|| A text node
|-
| <tt>                                        </tt><tt><foreign>grande croissant</foreign></tt>
|| A <tt><foreign></tt> element that itself contains one text node
|-
| <tt>                                                                           . I didn't!      </tt>
|| A text node that includes a carriage return and then two spaces
|-
|}

By convention, it is presumed that this encodes a passage that could have been equivalently encoded one of these ways:

The 
<emph>cat</emph>
ate the 
<foreign>croissant</foreign>. 
I didn't!

The <emph>cat</emph> ate the <foreign>grande croissant</foreign>. I didn't!

The algorithm to normalize space in mixed content is:
* Collapse all white space, then
* trim:
** trim leading space on the first text node in an element and
** trim trailing space on the last text node in an element,
** trim both if a text node is both first and last, i.e., is the only text node in the element.

Applying that algorithm to the above passage:
{| class="wikitable"
|-
| <tt>      </tt><tt>  The </tt> 
<tt>        </tt><tt>The </tt>
|| Because this is the first node in the element, leading space is trimmed and trailing space is collapsed but not trimmed.
|-
| <tt>            </tt><tt><emph> cat </emph></tt> 
<tt>                   cat      </tt>
|| Because the only thing inside the <emph> element is a text node, the text there gets collapsed and trimmed.
|-
| <tt>                               </tt><tt> ate  the </tt> 
<tt>                               </tt><tt> ate the </tt>
|| Space is collapsed but not trimmed on either side.
|-
| <tt>                                        <foreign>grande croissant</foreign></tt> 
<tt>                                                 grande croissant</tt>

|| Space in this text-only node is collapsed and trimmed, but no change results.
|-
| <tt>                                                                         . I didn't!</tt> <tt>     </tt> 
<tt>                                                                         . I didn't!</tt>
|| Because this is the last node in the element, trailing space is trimmed and leading space is collapsed but not trimmed.
|-
|}
The result is as if the encoding had been
The <emph>cat</emph> ate the <foreign>grande croissant</foreign>. I didn't!

'''Note:''' The normalization process would have corrupted the text had the encoder put spaces ''inside'' the <emph>, like this:
The<emph> cat </emph>ate the <foreign>grande croissant</foreign>. I didn't!

The resulting text would be:

Thecatate the ''grande croissant''. I didn't!

'''An encoder should assume that an element that includes nothing but text ''will'' get trimmed.'''

== Structured Elements and xsl:strip-space ==

As mentioned above, normalization of whitespace is very common. Programmers implement it without asking encoders. And encoders presume some downstream application will effect it. This complex encoding of a person's name, [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-persName.html taken from the TEI 5 Guidelines] and mentioned above,

<persName>
 <forename>Edward</forename>
 <forename>George</forename>
 <surname type="linked">Bulwer-Lytton</surname>, <roleName>Baron Lytton of
 <placeName>Knebworth</placeName>
 </roleName>
</persName>

presumes—though without saying so—that a downstream program will normalize space according to the algorithm above and produce the name <tt>Edward George Bulwer-Lytton, Baron Lytton of Knebworth</tt>.

Note here that the <tt><persName></tt> element contains both text and elements. Note the comma. And note that had the forenames been encoded without intervening whitespace, the result would have been <tt>EdwardGeorge</tt>.

A problem lurks. Part of defining an XML vocabulary such as TEI is specifying whether an element may contain text and elements or just elements. In TEI 5, <tt><address></tt>, for example, unlike <tt><persName></tt>, may only contain other elements. This

<address>
 <street>10 Downing Street</street>
 <settlement>London</settlement>
 <postCode>SW1A 2AA</postCode>
<address>

is valid TEI. But this

<address>
 <street>10 Downing Street</street>,
 <settlement>London</settlement>
 <postCode>SW1A 2AA</postCode>
<address>

is not, because of that comma after the <tt><street></tt> element. Free non-whitespace text is not allowed between the elements that comprise the <tt><address></tt> element. Though the term is sometimes used more loosely, <tt><address></tt> would commonly be called a "structured element."

Elements that do not allow free non-whitespace text—structured elements, strictly speaking—mimic database records. When XML is used to move data between databases, such elements are the norm; indeed many XSLT programmers have never worked on anything but structured data. In a TEI file, structured data is more common in the header than in the text. A program extracting metadata from a TEI file will often be looking for structured data in the header, so that it can populate database fields, maybe like this:

street: 10 Downing Street 
settlement: London 
postCode: SW1A 2AA 

Defining an element as a structured element specifies that space between child elements can be completely ignored. Thus these two encodings

<address>
 <settlement type="city">London</settlement>
 <postCode>SW1A 2AA</postCode>
<address>

<address>
 <settlement type="city">London</settlement><postCode>SW1A 2AA</postCode>
<address>

are equivalent. They encode:

city: London 
postCode: SW1A 2AA 

Nothing in the encoding indicates that there should be a space, a comma, a new-line, or anything else between "London" and "SW1A 2AA". What, if anything, will be there is left to the processing application. When rendering prose, the application might insert a comma; when printing a mailing label, it might insert a new-line. If might use different punctuation when mailing to different countries.

To correctly process structured elements, XSL programmers insert an instruction, <tt><xsl:strip-space></tt>, at the beginning of their programs, followed by a list of the names of the structured elements. Among other things, this ensures that all whitespace between the children of structured elements will be removed. It will be as if such whitespace was collapsed and trimmed and made to completely disappear.

This situation can produce a temptation best resisted. An encoder may want to request that space be inserted between the components of a structured element, that, for example,

<address>
 <settlement type="city">London</settlement>
 <postCode>SW1A 2AA</postCode>
<address>

should be taken to encode "London SW1A 2AA". To implement this, the downstream processor could simply treat <tt><address></tt> as if it were not a structured element and was a mixed-content element instead. The encoder could then leave whitespace between the child elements and the regular normalization algorithm described above would collapse it and leave one space character.

The temptation is all the more seductive because (1) XML verification will not signal an error, (2) demands on the programmers of downstream applications are reduced, and (3) it is easy to succumb unknowingly. In XSLT, the programmer intentionally or inadvertently leaves <tt><xsl:strip-space></tt> off, something the programmer is happy to do since gathering the list of structured elements was inconvenient anyway, and all seems to be well.

But the better practice is indeed to burden the application with properly formatting structured elements. This burden is part of what it means for an element to be structured. If the project team agrees that whitespace in structured elements will be significant, the schema should be customized to make these elements mixed-content elements instead of structured elements. This ensures that future users of the XML files will be able to understand the files' contents. It also signals that

<tt><settlement>New</settlement><settlement>York</settlement></tt>

and

<tt><settlement>New</settlement> <settlement>York</settlement></tt>

are different, which they would not be if the element were a structured one.

== Recommendations ==

* Programmers should, unless instructed otherwise by <tt>@xml:space='preserve'</tt>, implement code that normalizes space.
* Encoders should presume such normalization will be done but should include a note in <tt><encodingDesc></tt> announcing the presumption. If normalization is not desired as the default, this certainly should be announced in <tt><encodingDesc></tt>
* Encoders should use <tt>xml:space='preserve'</tt> only with the utmost care. Whatever could be accomplished by using it is usually accomplished with less risk by using native TEI elements.
* Project teams should not intentionally or inadvertently use structured elements as if they were mixed-content elements. If this must be done, the schema should be customized to record the change.

== XSLT Normalization Code ==

To normalize mixed-content elements, XSLT's <tt>normalize-space()</tt> function cannot simply be used on all text nodes. The XSLT stylesheet must consider where a text node is among its siblings.

The following XSLT 1.0 code implements the normalization algorithm described above. It works for both text-only and mixed-content elements. The code overrides the built-in template for the appropriate text nodes so may simply be added to XSLT stylesheets.
<pre>

<xsl:template match="text()[not(ancestor::*[@xml:space][1]/@xml:space='preserve')]">

<xsl:if test="position()!=1 and normalize-space(substring(., 1, 1)) = '' and normalize-space()!=''">
<xsl:text> </xsl:text>
</xsl:if>
<xsl:value-of select="normalize-space()"/>

<xsl:if test="position()!=last() and position()!=1 and normalize-space(substring(., string-length())) = ''
or position()!=last() and position() =1 and normalize-space(substring(., string-length())) = '' and normalize-space()!=''
or last()=1 and string-length()!=0 and normalize-space()='' ">
<xsl:text> </xsl:text>
</xsl:if>
</xsl:template>
</pre>
The <tt>normalize-space(substring(., string-length())) = <nowiki>''</nowiki></tt> is just a way to test for whitespace.

An alternative in XSLT 2.0 is the code below, which covers all uses of <tt>text()</tt>. it is written in a slightly more verbose style than the XSLT 1.0 version.

<pre>
<xsl:template match="text()">
<xsl:choose>
<xsl:when
test="ancestor::*[@xml:space][1]/@xml:space='preserve'">
<xsl:value-of select="."/>
</xsl:when>
<xsl:otherwise>

<xsl:if test="position()!=1 and
matches(.,'^\s') and
normalize-space()!=''">
<xsl:text> </xsl:text>
</xsl:if>
<xsl:value-of select="."/>
<xsl:choose>

<xsl:when test="last()=1 and string-length()!=0 and normalize-space()=''">
<xsl:text> </xsl:text>
</xsl:when>

<xsl:when test="position()!=1 and position()!=last() and matches(.,'\s$')">
<xsl:text> </xsl:text>
</xsl:when>

<xsl:when test="position()=1 and matches(.,'\s$') and normalize-space()!=''">
<xsl:text> </xsl:text>
</xsl:when>
</xsl:choose>
</xsl:otherwise>
</xsl:choose>
</xsl:template>
</pre>

Sometimes this code will give the wrong result, as the result of <tt>position()</tt> applied to <tt>text()</tt> does not always return the right result. A more
foolproof method is
<pre>
<xsl:template match="text()">
<xsl:variable name="first" select="if (preceding-sibling::text()) then false() else true() "/>
<xsl:variable name="more" select="if (following-sibling::text()) then false() else true() "/>
<xsl:choose>
<xsl:when
test="ancestor::*[@xml:space][1]/@xml:space='preserve'">
<xsl:value-of select="normalize-space(.)"/>
</xsl:when>
<xsl:otherwise>

<xsl:if test="not($first) and
matches(.,'^\s') and
normalize-space()!=''">
<xsl:call-template name="space"/>
</xsl:if>
<xsl:value-of select="normalize-space(.)"/>
<xsl:choose>

<xsl:when test="$first and not ($more) and
string-length()!=0 and
normalize-space()=''">
<xsl:call-template name="space"/>
</xsl:when>

<xsl:when test="not($first) and $more and matches(.,'\s$')">
<xsl:call-template name="space"/>
</xsl:when>

<xsl:when test="$first and $more and matches(.,'\s$') and
normalize-space()!=''">
<xsl:call-template name="space"/>
</xsl:when>
</xsl:choose>
</xsl:otherwise>
</xsl:choose>
</xsl:template>
</pre>

== External Links ==
*[http://www.w3.org/TR/REC-xml/#sec-white-space XML 1.0 (Fifth Edition W3C Recommendation 26 November 2008) 2.10 White Space Handling] The spec on @xml:space.
*[http://www.jenitennison.com/blog/node/41 Things that make me scream: xml:space="preserve" in WordML] Frustrations of dealing with @xml:space.
*[http://lists.xml.org/archives/xml-dev/201207/msg00172.html What is @xml:space about?] A discussion of @xml:space on xml-dev.
*[http://msdn.microsoft.com/en-us/library/ms788746(v=vs.90).aspx Whitespace Processing in XAML] Another description of the algorithm for normalizing mixed-content elements.

[[Category:XSLT]]
[[Category:Markup]]
[[Category:Recommended Practice]]

Tei-xsl

2013-07-29T14:44:08Z

Rahtz: /* Get from Subversion */

[[Category:Tools]]

[[Category:Conversion and preprocessing tools]]
[[Category:Publishing and delivery tools]]
[[Category:XSLT]]

== Synopsis ==
"This is a set of XSLT 2.0 specifications to transform TEI XML documents to XHTML, to LaTeX, to XSL Formatting Objects, to/from OOXML (docx), to/from OpenOfice (odt) and to ePub format. [. . .] They concentrate on the simpler TEI modules, but adding support for other modules is fairly easy. In the main, the setup has been used on ‘new’ documents, ie reports and web pages that have been authored from scratch, rather than traditional TEI-encoded existing material."<ref>http://www.tei-c.org/Tools/Stylesheets/</ref>

== Features ==

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

== System requirements ==
"The XSL FO style sheets were developed for use with PassiveTeX (http://projects.oucs.ox.ac.uk/passivetex/), a system using XSL formatting objects to render XML to PDF via LaTeX. They have not been extensively tested with the other XSL FO implementations."<ref>http://www.tei-c.org/Tools/Stylesheets/</ref>

Software dependencies:

* Saxon 9.2 or later. If using Debian or Ubuntu, you can get it from http://tei.oucs.ox.ac.uk/teideb/ .
* ant and ant-contrib. Note that as of 2011-11-30, ant-contrib is not availabe as as RedHat package.

== Source code and licensing ==
Freely available.

== Support for TEI ==

== Language(s) ==
Documentation is in English.

== Documentation ==
These two pages should be identical and therefore equally authoritative:

* http://www.tei-c.org/Tools/Stylesheets/
* http://www.tei-c.org/release/doc/tei-xsl-common/

Among the components of this package of stylesheets not documented are the following:

* <code>tools/oddbyexample.xsl</code> – generates a list of all the attribute values used in the directory of texts you apply it to, in the form of an [[ODD]] file, from which you can in turn generate documentation and schemas using Roma
* <code>tools/odd2nuodd.xsl</code> – switches from a traditional ODD-by-exclusion to a newer form ODD-by-inclusion

See also this guide by Lauara Mandell, which contains some documentation and some videos: http://idhmc.tamu.edu/chat/xslt/modifyTEI.html

=== Creating a custom profile ===

To create a profile for converting to/from a format and TEI XML, create either or both as needed:

<code>profiles/$PROFILENAME/$FORMAT/to.xsl</code>

<code>profiles/$PROFILENAME/$FORMAT/from.xsl</code>

Start by copying the files in <code>profiles/default/$FORMAT/</code> and then adding your own overrides and/or additional templates. See [http://listserv.brown.edu/archives/cgi-bin/wa?A2=ind1303&L=TEI-L&F=&S=&P=99998 this brief example of additional templates].

Note that if your <code>$FORMAT</code> is docx, this directory must contain a file <code>template.docx</code> which is used to create .docx files from. See the sample in the default profile.

=== Converting from DOCX format ===

Word has two kinds of styles: paragraph styles and character styles. According to Sebastian, "The basic rule of the conversion is that if named [character] styles are used, they take precedence over manual formatting." That is, if text (even a whole paragraph) has a character style applied but is also marked in Word as being italicized, the italics will not come through in the conversion separate from the character style. This is the single biggest defect in the system (according to Lou, and Ron!)

== Tech support ==

== User community ==

== Sample implementations ==

The package includes a number of profiles in the <code>profiles/</code> directory.

== Current version number and date of release ==

6.38 (2013-07-26)

== History of versions ==

See https://sourceforge.net/projects/tei/files/Stylesheets/ .

== How to download or buy ==

If you use [[Oxygen]], the easiest thing to do might be to download as part of [http://code.google.com/p/oxygen-tei/ oxygen-tei], the open-source TEI framework built into <oXygen/>. Otherwise, there are three options:

=== Download zip file ===
Download the latest zip file (below all of the folders) from https://sourceforge.net/projects/tei/files/Stylesheets/ .

=== Install the Debian package ===

Install the <code>tei-xsl</code> Debian package from the [http://tei.oucs.ox.ac.uk/teideb/ list of Debian packages].

=== Get from Github ===

<code>
git clone git@github.com:TEIC/Stylesheets.git /path/to/local/directory/Stylesheets
</code>

Then, if you want to add these to <code>/usr/</code> (which you will need to do in order to use the command-line shell scripts), you can do the following:

<code>
cd /path/to/local/directory/Stylesheets/
</code>

<code>
make install
</code>

but note the following:

* You will need to run <code>make install</code> as a user with write permission to <code>/usr/</code> . So if using Ubuntu, for example, you will need to instead do <code>sudo make install</code> .

== Additional notes ==
The XSLT 1.0 version of this stylesheet family, which is no longer actively maintained, can be found on Github at https://github.com/sebastianrahtz/TEIXSL-v1.git

== Notes ==

<references/>

Tei-xsl

2013-07-29T14:38:53Z

Rahtz: /* Get from Subversion */

[[Category:Tools]]

[[Category:Conversion and preprocessing tools]]
[[Category:Publishing and delivery tools]]
[[Category:XSLT]]

== Synopsis ==
"This is a set of XSLT 2.0 specifications to transform TEI XML documents to XHTML, to LaTeX, to XSL Formatting Objects, to/from OOXML (docx), to/from OpenOfice (odt) and to ePub format. [. . .] They concentrate on the simpler TEI modules, but adding support for other modules is fairly easy. In the main, the setup has been used on ‘new’ documents, ie reports and web pages that have been authored from scratch, rather than traditional TEI-encoded existing material."<ref>http://www.tei-c.org/Tools/Stylesheets/</ref>

== Features ==

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

== System requirements ==
"The XSL FO style sheets were developed for use with PassiveTeX (http://projects.oucs.ox.ac.uk/passivetex/), a system using XSL formatting objects to render XML to PDF via LaTeX. They have not been extensively tested with the other XSL FO implementations."<ref>http://www.tei-c.org/Tools/Stylesheets/</ref>

Software dependencies:

* Saxon 9.2 or later. If using Debian or Ubuntu, you can get it from http://tei.oucs.ox.ac.uk/teideb/ .
* ant and ant-contrib. Note that as of 2011-11-30, ant-contrib is not availabe as as RedHat package.

== Source code and licensing ==
Freely available.

== Support for TEI ==

== Language(s) ==
Documentation is in English.

== Documentation ==
These two pages should be identical and therefore equally authoritative:

* http://www.tei-c.org/Tools/Stylesheets/
* http://www.tei-c.org/release/doc/tei-xsl-common/

Among the components of this package of stylesheets not documented are the following:

* <code>tools/oddbyexample.xsl</code> – generates a list of all the attribute values used in the directory of texts you apply it to, in the form of an [[ODD]] file, from which you can in turn generate documentation and schemas using Roma
* <code>tools/odd2nuodd.xsl</code> – switches from a traditional ODD-by-exclusion to a newer form ODD-by-inclusion

See also this guide by Lauara Mandell, which contains some documentation and some videos: http://idhmc.tamu.edu/chat/xslt/modifyTEI.html

=== Creating a custom profile ===

To create a profile for converting to/from a format and TEI XML, create either or both as needed:

<code>profiles/$PROFILENAME/$FORMAT/to.xsl</code>

<code>profiles/$PROFILENAME/$FORMAT/from.xsl</code>

Start by copying the files in <code>profiles/default/$FORMAT/</code> and then adding your own overrides and/or additional templates. See [http://listserv.brown.edu/archives/cgi-bin/wa?A2=ind1303&L=TEI-L&F=&S=&P=99998 this brief example of additional templates].

Note that if your <code>$FORMAT</code> is docx, this directory must contain a file <code>template.docx</code> which is used to create .docx files from. See the sample in the default profile.

=== Converting from DOCX format ===

Word has two kinds of styles: paragraph styles and character styles. According to Sebastian, "The basic rule of the conversion is that if named [character] styles are used, they take precedence over manual formatting." That is, if text (even a whole paragraph) has a character style applied but is also marked in Word as being italicized, the italics will not come through in the conversion separate from the character style. This is the single biggest defect in the system (according to Lou, and Ron!)

== Tech support ==

== User community ==

== Sample implementations ==

The package includes a number of profiles in the <code>profiles/</code> directory.

== Current version number and date of release ==

6.38 (2013-07-26)

== History of versions ==

See https://sourceforge.net/projects/tei/files/Stylesheets/ .

== How to download or buy ==

If you use [[Oxygen]], the easiest thing to do might be to download as part of [http://code.google.com/p/oxygen-tei/ oxygen-tei], the open-source TEI framework built into <oXygen/>. Otherwise, there are three options:

=== Download zip file ===
Download the latest zip file (below all of the folders) from https://sourceforge.net/projects/tei/files/Stylesheets/ .

=== Install the Debian package ===

Install the <code>tei-xsl</code> Debian package from the [http://tei.oucs.ox.ac.uk/teideb/ list of Debian packages].

=== Get from Subversion ===

<code>
git clone git@github.com:TEIC/Stylesheets.git /path/to/local/directory/
</code>

Then, if you want to add these to <code>/usr/</code> (which you will need to do in order to use the command-line shell scripts), you can do the following:

<code>
cd /path/to/local/directory/Stylesheets/
</code>

<code>
make install
</code>

but note the following:

* You will need to run <code>make install</code> as a user with write permission to <code>/usr/</code> . So if using Ubuntu, for example, you will need to instead do <code>sudo make install</code> .

== Additional notes ==
The XSLT 1.0 version of this stylesheet family, which is no longer actively maintained, can be found on Github at https://github.com/sebastianrahtz/TEIXSL-v1.git

== Notes ==

<references/>

Tei-xsl

2013-07-29T14:38:38Z

Rahtz: /* Get from Subversion */

[[Category:Tools]]

[[Category:Conversion and preprocessing tools]]
[[Category:Publishing and delivery tools]]
[[Category:XSLT]]

== Synopsis ==
"This is a set of XSLT 2.0 specifications to transform TEI XML documents to XHTML, to LaTeX, to XSL Formatting Objects, to/from OOXML (docx), to/from OpenOfice (odt) and to ePub format. [. . .] They concentrate on the simpler TEI modules, but adding support for other modules is fairly easy. In the main, the setup has been used on ‘new’ documents, ie reports and web pages that have been authored from scratch, rather than traditional TEI-encoded existing material."<ref>http://www.tei-c.org/Tools/Stylesheets/</ref>

== Features ==

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

== System requirements ==
"The XSL FO style sheets were developed for use with PassiveTeX (http://projects.oucs.ox.ac.uk/passivetex/), a system using XSL formatting objects to render XML to PDF via LaTeX. They have not been extensively tested with the other XSL FO implementations."<ref>http://www.tei-c.org/Tools/Stylesheets/</ref>

Software dependencies:

* Saxon 9.2 or later. If using Debian or Ubuntu, you can get it from http://tei.oucs.ox.ac.uk/teideb/ .
* ant and ant-contrib. Note that as of 2011-11-30, ant-contrib is not availabe as as RedHat package.

== Source code and licensing ==
Freely available.

== Support for TEI ==

== Language(s) ==
Documentation is in English.

== Documentation ==
These two pages should be identical and therefore equally authoritative:

* http://www.tei-c.org/Tools/Stylesheets/
* http://www.tei-c.org/release/doc/tei-xsl-common/

Among the components of this package of stylesheets not documented are the following:

* <code>tools/oddbyexample.xsl</code> – generates a list of all the attribute values used in the directory of texts you apply it to, in the form of an [[ODD]] file, from which you can in turn generate documentation and schemas using Roma
* <code>tools/odd2nuodd.xsl</code> – switches from a traditional ODD-by-exclusion to a newer form ODD-by-inclusion

See also this guide by Lauara Mandell, which contains some documentation and some videos: http://idhmc.tamu.edu/chat/xslt/modifyTEI.html

=== Creating a custom profile ===

To create a profile for converting to/from a format and TEI XML, create either or both as needed:

<code>profiles/$PROFILENAME/$FORMAT/to.xsl</code>

<code>profiles/$PROFILENAME/$FORMAT/from.xsl</code>

Start by copying the files in <code>profiles/default/$FORMAT/</code> and then adding your own overrides and/or additional templates. See [http://listserv.brown.edu/archives/cgi-bin/wa?A2=ind1303&L=TEI-L&F=&S=&P=99998 this brief example of additional templates].

Note that if your <code>$FORMAT</code> is docx, this directory must contain a file <code>template.docx</code> which is used to create .docx files from. See the sample in the default profile.

=== Converting from DOCX format ===

Word has two kinds of styles: paragraph styles and character styles. According to Sebastian, "The basic rule of the conversion is that if named [character] styles are used, they take precedence over manual formatting." That is, if text (even a whole paragraph) has a character style applied but is also marked in Word as being italicized, the italics will not come through in the conversion separate from the character style. This is the single biggest defect in the system (according to Lou, and Ron!)

== Tech support ==

== User community ==

== Sample implementations ==

The package includes a number of profiles in the <code>profiles/</code> directory.

== Current version number and date of release ==

6.38 (2013-07-26)

== History of versions ==

See https://sourceforge.net/projects/tei/files/Stylesheets/ .

== How to download or buy ==

If you use [[Oxygen]], the easiest thing to do might be to download as part of [http://code.google.com/p/oxygen-tei/ oxygen-tei], the open-source TEI framework built into <oXygen/>. Otherwise, there are three options:

=== Download zip file ===
Download the latest zip file (below all of the folders) from https://sourceforge.net/projects/tei/files/Stylesheets/ .

=== Install the Debian package ===

Install the <code>tei-xsl</code> Debian package from the [http://tei.oucs.ox.ac.uk/teideb/ list of Debian packages].

=== Get from Subversion ===

<code>
git cline git@github.com:TEIC/Stylesheets.git /path/to/local/directory/
</code>

Then, if you want to add these to <code>/usr/</code> (which you will need to do in order to use the command-line shell scripts), you can do the following:

<code>
cd /path/to/local/directory/Stylesheets/
</code>

<code>
make install
</code>

but note the following:

* You will need to run <code>make install</code> as a user with write permission to <code>/usr/</code> . So if using Ubuntu, for example, you will need to instead do <code>sudo make install</code> .

== Additional notes ==
The XSLT 1.0 version of this stylesheet family, which is no longer actively maintained, can be found on Github at https://github.com/sebastianrahtz/TEIXSL-v1.git

== Notes ==

<references/>

Tei-xsl

2013-07-29T14:36:22Z

Rahtz: /* Documentation */

[[Category:Tools]]

[[Category:Conversion and preprocessing tools]]
[[Category:Publishing and delivery tools]]
[[Category:XSLT]]

== Synopsis ==
"This is a set of XSLT 2.0 specifications to transform TEI XML documents to XHTML, to LaTeX, to XSL Formatting Objects, to/from OOXML (docx), to/from OpenOfice (odt) and to ePub format. [. . .] They concentrate on the simpler TEI modules, but adding support for other modules is fairly easy. In the main, the setup has been used on ‘new’ documents, ie reports and web pages that have been authored from scratch, rather than traditional TEI-encoded existing material."<ref>http://www.tei-c.org/Tools/Stylesheets/</ref>

== Features ==

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

== System requirements ==
"The XSL FO style sheets were developed for use with PassiveTeX (http://projects.oucs.ox.ac.uk/passivetex/), a system using XSL formatting objects to render XML to PDF via LaTeX. They have not been extensively tested with the other XSL FO implementations."<ref>http://www.tei-c.org/Tools/Stylesheets/</ref>

Software dependencies:

* Saxon 9.2 or later. If using Debian or Ubuntu, you can get it from http://tei.oucs.ox.ac.uk/teideb/ .
* ant and ant-contrib. Note that as of 2011-11-30, ant-contrib is not availabe as as RedHat package.

== Source code and licensing ==
Freely available.

== Support for TEI ==

== Language(s) ==
Documentation is in English.

== Documentation ==
These two pages should be identical and therefore equally authoritative:

* http://www.tei-c.org/Tools/Stylesheets/
* http://www.tei-c.org/release/doc/tei-xsl-common/

Among the components of this package of stylesheets not documented are the following:

* <code>tools/oddbyexample.xsl</code> – generates a list of all the attribute values used in the directory of texts you apply it to, in the form of an [[ODD]] file, from which you can in turn generate documentation and schemas using Roma
* <code>tools/odd2nuodd.xsl</code> – switches from a traditional ODD-by-exclusion to a newer form ODD-by-inclusion

See also this guide by Lauara Mandell, which contains some documentation and some videos: http://idhmc.tamu.edu/chat/xslt/modifyTEI.html

=== Creating a custom profile ===

To create a profile for converting to/from a format and TEI XML, create either or both as needed:

<code>profiles/$PROFILENAME/$FORMAT/to.xsl</code>

<code>profiles/$PROFILENAME/$FORMAT/from.xsl</code>

Start by copying the files in <code>profiles/default/$FORMAT/</code> and then adding your own overrides and/or additional templates. See [http://listserv.brown.edu/archives/cgi-bin/wa?A2=ind1303&L=TEI-L&F=&S=&P=99998 this brief example of additional templates].

Note that if your <code>$FORMAT</code> is docx, this directory must contain a file <code>template.docx</code> which is used to create .docx files from. See the sample in the default profile.

=== Converting from DOCX format ===

Word has two kinds of styles: paragraph styles and character styles. According to Sebastian, "The basic rule of the conversion is that if named [character] styles are used, they take precedence over manual formatting." That is, if text (even a whole paragraph) has a character style applied but is also marked in Word as being italicized, the italics will not come through in the conversion separate from the character style. This is the single biggest defect in the system (according to Lou, and Ron!)

== Tech support ==

== User community ==

== Sample implementations ==

The package includes a number of profiles in the <code>profiles/</code> directory.

== Current version number and date of release ==

6.38 (2013-07-26)

== History of versions ==

See https://sourceforge.net/projects/tei/files/Stylesheets/ .

== How to download or buy ==

If you use [[Oxygen]], the easiest thing to do might be to download as part of [http://code.google.com/p/oxygen-tei/ oxygen-tei], the open-source TEI framework built into <oXygen/>. Otherwise, there are three options:

=== Download zip file ===
Download the latest zip file (below all of the folders) from https://sourceforge.net/projects/tei/files/Stylesheets/ .

=== Install the Debian package ===

Install the <code>tei-xsl</code> Debian package from the [http://tei.oucs.ox.ac.uk/teideb/ list of Debian packages].

=== Get from Subversion ===

<code>
svn co https://tei.svn.sourceforge.net/svnroot/tei/trunk/ /path/to/local/directory/
</code>

Then, if you want to add these to <code>/usr/</code> (which you will need to do in order to use the command-line shell scripts), you can do the following:

<code>
cd /path/to/local/directory/Stylesheets/
</code>

<code>
make install
</code>

but note the following:

* You should not download just the stylesheets module (using <code>svn co https://tei.svn.sourceforge.net/svnroot/tei/trunk/Stylesheets/</code> ) because <code>Stylesheets/Makefile</code> requires that other modules be present.
* You will need to run <code>make install</code> as a user with write permission to <code>/usr/</code> . So if using Ubuntu, for example, you will need to instead do <code>sudo make install</code> .

== Additional notes ==
The XSLT 1.0 version of this stylesheet family, which is no longer actively maintained, can be found on Github at https://github.com/sebastianrahtz/TEIXSL-v1.git

== Notes ==

<references/>

OxGarage

2013-07-02T18:47:04Z

Rahtz:

[[Category:Tools]]

[[Category:Conversion and preprocessing tools]]

== Synopsis ==
[http://www.oucs.ox.ac.uk/oxgarage/ OxGarage] is a web, and RESTful, service to manage the transformation of documents between a variety of formats. The majority of transformations use the Text Encoding Initiative format as a pivot format. It is a good tool for conversion from TEI to Word (.docx), or Word (.docx) to TEI, but also does many other formats.

There is a [http://www.oucs.ox.ac.uk/oxgarage/matrix.xml list of formats for conversion to and from] which OxGarage supports.
Some of these use [[Tei-xsl|XSLT-based transformations]] and others are provided by [http://www.artofsolving.com/opensource/jodconverter JODConverter].

== Features ==

OxGarage can be used to
* Convert TEI documents to HTML, LaTeX, Word, OpenOffice, and ePub
* Process TEI ODD documents to make schemas or documentation
* Convert Word documents to TEI
* Transform some common XML formats (NLM, P4, Docbook) to or from TEI
* Manage any of the document conversions supported by OpenOffice

A user uploads a document, chooses the target format, OxGarage works out the pipeline of required transformation steps, performs them, and returns the resulting new document. For example, an ODD document can be turned into ePub by

# expanding the ODD file by merging with the TEI P5 source
# converting the resulting XML to TEI Lite for formatting
# transforming TEI Lite XML to HTML and packaging as ePub

OxGarage takes care of all three stages, the user does not need to know about the middle stage. All transformations using TEI are
performed with XSLT 2.0 stylesheets, some other transformations use JODConverter and a headless OpenOffice instance.

The results for some transformations can be tweaked by choosing different output profiles. These are defined on the OxGarage server.

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

== System requirements ==
A standard modern web browser is all that is required to make use of the Web Client. If you want to deploy the underlying system yourself you need Sun/Oracle Java 6 JRE, Tomcat, OpenOffice, etc. To build it you also need Maven and various java libraries, and a Debian setup is provided. For more information see http://www.oucs.ox.ac.uk/oxgarage/install.xml

== Source code and licensing ==
OxGarage source code is hosted on Github, at https://github.com/sebastianrahtz/oxgarage;
is is a fork and extension of the EGE project (on Sourceforge: http://enrich-ege.sourceforge.net/)
and is licensed under the GPL.

== Support for TEI ==
The basic stylesheets provided with OxGarage (and ENRICH-EGE) use TEI as an output and pivot format.

== Language(s) ==
The Web Client and Documentation is only provided in English

== Documentation ==
See links at http://www.oucs.ox.ac.uk/oxgarage/ and http://enrich-ege.sourceforge.net/

== Tech support ==

Contact oxgarage@oucs.ox.ac.uk for best-effort support concerning the OxGarage customisation.

== User community ==

== Sample implementations ==

* http://www.tei-c.org/oxgarage/ -- this sometimes uses an older release of the software
* http://oxgarage.oucs.ox.ac.uk:8080/ege-webclient/

== Current version number and date of release ==

Version 2.1.2 June 2013

== History of versions ==

== How to download or buy ==

Download either:
* from Github (https://github.com/sebastianrahtz/oxgarage)
* as a Debian package from http://tei.oucs.ox.ac.uk/teideb/

== Additional notes ==
Test version is at http://oxgarage.oucs.ox.ac.uk:8080/ege-webclient/

== References ==

<references/>

Council actions 2013-04

2013-04-22T15:23:56Z

Rahtz:

A list of actions, those responsible, and what has been done about them
from Providence, Rhode Island, 2013-04-11 to 2013-04-13 face to face
meeting of TEI Technical Council
{|class="wikitable"
|'''Who'''
|'''What'''
|'''Suggested Deadline'''
|'''Result (What Was Done)'''
|-
|All of Council
|read and comment on the document (even if it's "this bit doesn't make sense to me"). http://goo.gl/AwPs6
|2013-05-17
|
|-
|EM
|to clarify the description on elementSpec on biblScope, citedRange and locus to clarify the use of @from and @to. https://sourceforge.net/p/tei/feature-requests/389/
|2013-06-07
|
|-
|EM and SB
|to take over from KH and get something from the phys bibl group, and/or encourage the generation of cheatsheets for encoding physical bibliography to go on the wiki. [— addendum, 2013-04-14 by Syd: I believe this action was on EM and SB (or perhaps EM, LB, SB); in any case, I have already spoken to Richard Noble who is not only on board but eager. —]
|2013-05-31
|
|-
|GB
|to add examples of schematron constrains on contents of <app> as the (Green) ticket says.
|2013-05-31
|
|-
|GB
|to re-read the section and rephrase/rewrite if necessary. https://sourceforge.net/p/tei/bugs/552/
|2013-05-31
|
|-
|GB
|to close the ticket with explanation, and possibly revise the text to clarify. *DONE* https://sourceforge.net/p/tei/bugs/553/
|2013-04-30
|
|-
|GB
|Close https://sourceforge.net/p/tei/bugs/405/ if fully incorporated into HC's proposal
|2013-04-30
|
|-
|GB
|look at other suggested standards recording s<nowiki/>ex, gender, and gender identity for inclusion in the notes. https://sourceforge.net/p/tei/feature-requests/425/
|2013-04-30
|
|-
|GB
|Implement https://sourceforge.net/p/tei/feature-requests/425/ changing data.s<nowiki/>ex to be datatype data.word, providing changed Guidelines prose and notes to other standards.
|2013-04-30
|
|-
|GB
|to propose a more effective wording incorporating all the nuances. https//sourceforge.net/p/tei/bugs/543/
|2013-05-31
|
|-
|HC
|to change values in @unit to singular, spelled-out forms, add column, and update Guidelines examples and text for consistency with the new values. Leave @type alone because it's deprecated. https://sourceforge.net/p/tei/feature-requests/429/
|2013-05-17
|
|-
|HC
|Nudge NH, SB, and PB for input.
|2013-05-31
|
|-
|HC and SB
|specification and estimated cost for Xpointer resolver
|2013-05-31
|
|-
|HC and SR
|to test the use of @xml:space to solve this specific problem, and to see whether that's the correct solution in the long term. DONE; https://sourceforge.net/p/tei/bugs/544/
|2013-04-30
|DONE
|-
|JC
|to implement https://sourceforge.net/p/tei/feature-requests/449/ add <am> to att.typed.
|2013-04-30
|
|-
|JC
|to close ticket https://sourceforge.net/p/tei/feature-requests/438/ as won't-fix.
|2013-04-30
|
|-
|JC
|to put a copy of the SF XML dump in the Vault.
|2013-04-30
|
|-
|JC
|to talk to DavidS and ShayneB to find out if we'd be allowed to dump the wiki db, make changes, and re-upload. For the OpenCMS we could do it manually.
|2013-04-30
|
|-
|JC
|to email sourceforge and find out if we can turn this off or modify markdown setup and investigate the implications/options.
|2013-04-30
|
|-
|JC
|https://sourceforge.net/p/tei/bugs/504/ implement (already done.) Close Ticket.
|2013-04-30
|
|-
|JC
|to investigate the Allura system if possible to make the meanings of the numbers explicit.
|2013-04-30
|
|-
|JC
|to fix this (change "seven" to "four"). https://sourceforge.net/p/tei/bugs/555/
|2013-04-30
|
|-
|JC
|get back in touch with SIG conveners to encourage them to become active.
|2013-05-31
|
|-
|JC
|Inform CMC SIG of their acceptance.
|2013-04-30
|
|-
|JC
|Decide on deadlines for actions, but add them to the wiki not official minutes.
|2013-04-22
|DONE!
|-
|JC
|Schedule next teleconference.
|2013-05-17
|
|-
|JC
|to prod PB on all tickets assigned to him.
|2013-05-31
|
|-
|JC
|Ensure minutes are tidied up, posted online, summarised and that summary posted to TEI-L.
|2013-04-30
|
|-
|JC and LB
|specification and estimated cost for new web Roma, etc.
|2013-05-31
|
|-
|JC and SB
|to encourage Piotr to get some people into a room in Rome to discuss this. SB will attend to push the more generic viewpoint.
|2013-05-31
|
|-
|KH
|to email Council to solicit volunteers for TEI Google work, and provide a link to the samples again.
|2013-04-30
|DONE
|-
|KH
|to go through recent soft and hard deprecations and decide whether they're correct (hard) or not, to remove @status and add @validUntil attribute.
|2013-05-31
|
|-
|KH
|to address the original issue at his leisure. https://sourceforge.net/p/tei/bugs/496/
|2013-05-31
|
|-
|KH
|to close ticket wontfix. https://sourceforge.net/p/tei/bugs/493/
|2013-04-30
|
|-
|KH
|to implement the wording changes. https://sourceforge.net/p/tei/bugs/541/
|2013-05-31
|
|-
|KH
|change <idno> to <ref> or <pointer> as appropriate. The criterion to apply is whether the URL in question is an identifier or a link.
|2013-05-31
|
|-
|KH
|to add text to tcw24. Will look at how things are written in the introductory section about terminology. See if it needs adjustment. https://sourceforge.net/p/tei/bugs/548/
|2013-05-31
|
|-
|KH
|look for <note> near <egXML>, see which are just URL, change them to citations. KH will update tcw20.
|2013-05-31
|
|-
|KH to complete the ticket and close. https
|//sourceforge.net/p/tei/bugs/288/
|2013-05-17
|
|-
|LB
|to liaise with Mr Schmidt re audio and video ODD.
|2013-05-31
|
|-
|LB
|to implement ticket fr 437 https://sourceforge.net/p/tei/feature-requests/437/
|2013-05-31
|
|-
|LB
|specification and estimated cost for OmegaT
|2013-05-31
|
|-
|LB
|will request examples of use of @corresp on TEI-L to investigate looser uses
|2013-05-31
|
|-
|LB
|look into this and will clarify the note in element spec for publicationStmt to no longer imply that order of publisher, place of publication, etc. is mandatory if you use inside of <publicationStmt>.
|2013-05-31
|
|-
|LB
|Draft a message to TEI-L asking people to encode just a few samples by emailing back to TEI-L as a interim measure.
|2013-05-31
|
|-
|LB and MH
|Suggest idea of breaking up the chapters, <divs> into files with FlorenceC, report back on desirability or lack thereof. MH: suggests that there would be Canadian contributors to a French translation if that gets off the ground. MH to liaise or introduce them to FlorenceC
|2013-04-30
|
|-
|LB/PS/KH/MH (Div.liminal working group)
|to build the survey application for community markup method.
|2013-08-31
|
|-
|MH
|to implement https://sourceforge.net/p/tei/feature-requests/446/
|2013-05-31
|
|-
|MH
|to contact JM and resolve the ticket https://sourceforge.net/p/tei/feature-requests/402/ one way or the other.
|2013-05-17
|
|-
|MH
|to implement a draft of a new combined TOC and allow Council to comment https://sourceforge.net/p/tei/feature-requests/421/
|2013-05-31
|
|-
|MH
|to come up with a very concrete set of use cases for groups of elements and make very specific arguments for their needing @resp. https://sourceforge.net/p/tei/feature-requests/443/
|2013-05-17
|
|-
|MH
|to carry the remaining issues forward with Lou and Laurent to help as needed. https://sourceforge.net/p/tei/bugs/515/
|2013-05-31
|
|-
|MH
|to remove @scheme from <rendition> and replace it with the class; also it will then pick up the new @schemeVersion. https://sourceforge.net/p/tei/bugs/539/
|2013-05-31
|
|-
|MH
|investigate where we say these kinds of things and find a way to implement in XSLT, insert it into the make file so that it generates a <div> in a file, and XInclude that file into the first Guidelines chapter. https://sourceforge.net/p/tei/bugs/512/
|2013-07-31
|
|-
|MH
|Summarize to tei-council mailing list the text-directionality proposals and share the slides.
|2013-04-30
|
|-
|PS
|make new example for the <listOrg> section ND.html#NDORG. Add another example to the element spec for <listOrg> that refers to more typical listorgs. https://sourceforge.net/p/tei/bugs/558/
|2013-05-17
|
|-
|PS
|Select ~6-10 samples for div.liminal which evince the confusions we want help with.
|2013-05-17
|
|-
|RW
|to add proposed wording on <substJoin> to guidelines (and look for photograph of MS). https://sourceforge.net/p/tei/feature-requests/448/ (update to text is already done; remains to be seen whether the image can be found)
|2013-05-17
|
|-
|RW
|Fix https://sourceforge.net/p/tei/bugs/557/
|2013-04-30
|
|-
|RW and BB
|to categorize the table of attributes without examples by adding a column with priorities of high, medium and low.
|2013-05-31
|
|-
|SB
|send KH details about TEI-PB list [done 2013-04-21]
|2013-04-30
|DONE
|-
|SB
|to improve the elementSpec desc and add one or more examples. https://sourceforge.net/p/tei/feature-requests/443/
|2013-05-31
|
|-
|SB
|create @validUntil as a class and write Schematron checks for deprecations.
|2013-05-17
|
|-
|SB
|to rename the Specs-Unused directory to Defunct, and move the SH file into it.
|2013-05-17
|
|-
|SB
|to implement the current wording suggested above (See Minutes), as an interim measure. https://sourceforge.net/p/tei/bugs/543/
|2013-05-31
|
|-
|SB
|make <ptr>, <ref> consistent in component parts of <biblStruct>
|2013-05-31
|
|-
|SB
|remove our own dis-recommended use of <idno> in the bibliography
|2013-05-31
|
|-
|SB
|to implement https://sourceforge.net/p/tei/bugs/527/
|2013-05-31
|
|-
|SB
|add new tickets for the data.enumerated and valItem/@ident needing to be data.word not rng:text and xs:NCname, respectively.
|2013-05-31
|
|-
|SB
|post @rend, @rendition, @style class FR
|2013-04-30
|
|-
|SB and EM
|specification and estimated cost for oxygen front end for ODD.
|2013-05-31
|
|-
|SR
|to continue work on separating the Stylesheets from the guidelines into separate projects and solve problems with the Guidelines build process as a consumer of these. Any separation should be concentrating on making the latter more amenable to community development, reporting on back to Council.
|2013-05-17
|
|-
|SR
|to move the prose re <equiv/> from the core chapter into the tagdocs chapter, and tidy up. https://sourceforge.net/p/tei/bugs/516/
|2013-05-31
|DONE
|-
|SR
|to rewrite the paragraph again, to address other comments on the ticket. https://sourceforge.net/p/tei/bugs/549/
|2013-05-31
|DONE
|-
|SR
|rewrite the paragraph https://sourceforge.net/p/tei/bugs/550/
|2013-05-31
|DONE
|-
|SR
|when he gets the answer, he'll fix it, and definitive response will be sent to Jens. https://sourceforge.net/p/tei/bugs/560/
|2013-04-30
|DONE
|-
|SR
|Circulate ODD-related development papers to Council for comment
|2013-05-31
|DONE
|-
|SR and JC
|to investigate dates for next Council meeting, and set up a Doodle Poll.
|2013-05-31
|
|}
[[Category:Council]]

Tei-xsl

2013-03-13T09:55:07Z

Rahtz: /* Additional notes */

[[Category:Tools]]

[[Category:Conversion and preprocessing tools]]
[[Category:Publishing and delivery tools]]
[[Category:XSLT]]

== Synopsis ==
"This is a set of XSLT 2.0 specifications to transform TEI XML documents to XHTML, to LaTeX, to XSL Formatting Objects, to/from OOXML (docx), to/from OpenOfice (odt) and to ePub format. [. . .] They concentrate on the simpler TEI modules, but adding support for other modules is fairly easy. In the main, the setup has been used on ‘new’ documents, ie reports and web pages that have been authored from scratch, rather than traditional TEI-encoded existing material."<ref>http://www.tei-c.org/Tools/Stylesheets/</ref>

== Features ==

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

== System requirements ==
"The XSL FO style sheets were developed for use with PassiveTeX (http://projects.oucs.ox.ac.uk/passivetex/), a system using XSL formatting objects to render XML to PDF via LaTeX. They have not been extensively tested with the other XSL FO implementations."<ref>http://www.tei-c.org/Tools/Stylesheets/</ref>

Software dependencies:

* Saxon 9.2 or later. If using Debian or Ubuntu, you can get it from http://tei.oucs.ox.ac.uk/teideb/ .
* ant and ant-contrib. Note that as of 2011-11-30, ant-contrib is not availabe as as RedHat package.

== Source code and licensing ==
Freely available.

== Support for TEI ==

== Language(s) ==
Documentation is in English.

== Documentation ==
These two pages should be identical and therefore equally authoritative:

* http://www.tei-c.org/Tools/Stylesheets/
* http://www.tei-c.org/release/doc/tei-xsl-common/

Among the components of this package of stylesheets not documented are the following:

* <code>tools2/oddbyexample.xsl</code> – generates a list of all the attribute values used in the directory of texts you apply it to, in the form of an [[ODD]] file, from which you can in turn generate documentation and schemas using Roma
* <code>tools2/odd2nuodd.xsl</code> – switches from a traditional ODD-by-exclusion to a newer form ODD-by-inclusion

See also this guide by Lauara Mandell, which contains some documentation and some videos: http://idhmc.tamu.edu/chat/xslt/modifyTEI.html

=== Creating a custom profile ===

To create a profile for converting to/from a format and TEI XML, create either or both as needed:

<code>profiles/$PROFILENAME/$FORMAT/to.xsl</code>

<code>profiles/$PROFILENAME/$FORMAT/from.xsl</code>

Start by copying the files in <code>profiles/default/$FORMAT/</code> and then adding your own overrides.

Note that if your <code>$FORMAT</code> is docx, this directory must contain a file <code>template.docx</code> which is used to create .docx files from. See the sample in the default profile.

=== Converting from DOCX format ===

Word has two kinds of styles: paragraph styles and character styles. According to Sebastian, "The basic rule of the conversion is that if named [character] styles are used, they take precedence over manual formatting." That is, if text (even a whole paragraph) has a character style applied but is also marked in Word as being italicized, the italics will not come through in the conversion separate from the character style.

== Tech support ==

== User community ==

== Sample implementations ==

The package includes a number of profiles in the <code>profiles/</code> directory.

== Current version number and date of release ==

6.28 (2013-03-02)

== History of versions ==

See https://sourceforge.net/projects/tei/files/Stylesheets/ .

== How to download or buy ==

If you use [[Oxygen]], the easiest thing to do might be to download as part of [http://code.google.com/p/oxygen-tei/ oxygen-tei], the open-source TEI framework built into <oXygen/>. Otherwise, there are three options:

=== Download zip file ===
Download the latest zip file (below all of the folders) from https://sourceforge.net/projects/tei/files/Stylesheets/ .

=== Install the Debian package ===

Install the <code>tei-xsl</code> Debian package from the [http://tei.oucs.ox.ac.uk/teideb/ list of Debian packages].

=== Get from Subversion ===

<code>
svn co https://tei.svn.sourceforge.net/svnroot/tei/trunk/ /path/to/local/directory/
</code>

Then, if you want to add these to <code>/usr/</code> (which you will need to do in order to use the command-line shell scripts), you can do the following:

<code>
cd /path/to/local/directory/Stylesheets/
</code>

<code>
make install
</code>

but note the following:

* You should not download just the stylesheets module (using <code>svn co https://tei.svn.sourceforge.net/svnroot/tei/trunk/Stylesheets/</code> ) because <code>Stylesheets/Makefile</code> requires that other modules be present.
* You will need to run <code>make install</code> as a user with write permission to <code>/usr/</code> . So if using Ubuntu, for example, you will need to instead do <code>sudo make install</code> .

== Additional notes ==
The XSLT 1.0 version of this stylesheet family, which is no longer actively maintained, can be found on Github at https://github.com/sebastianrahtz/TEIXSL-v1.git

== Notes ==

<references/>

Tei-xsl

2013-03-13T09:54:19Z

Rahtz: /* Current version number and date of release */

[[Category:Tools]]

[[Category:Conversion and preprocessing tools]]
[[Category:Publishing and delivery tools]]
[[Category:XSLT]]

== Synopsis ==
"This is a set of XSLT 2.0 specifications to transform TEI XML documents to XHTML, to LaTeX, to XSL Formatting Objects, to/from OOXML (docx), to/from OpenOfice (odt) and to ePub format. [. . .] They concentrate on the simpler TEI modules, but adding support for other modules is fairly easy. In the main, the setup has been used on ‘new’ documents, ie reports and web pages that have been authored from scratch, rather than traditional TEI-encoded existing material."<ref>http://www.tei-c.org/Tools/Stylesheets/</ref>

== Features ==

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

== System requirements ==
"The XSL FO style sheets were developed for use with PassiveTeX (http://projects.oucs.ox.ac.uk/passivetex/), a system using XSL formatting objects to render XML to PDF via LaTeX. They have not been extensively tested with the other XSL FO implementations."<ref>http://www.tei-c.org/Tools/Stylesheets/</ref>

Software dependencies:

* Saxon 9.2 or later. If using Debian or Ubuntu, you can get it from http://tei.oucs.ox.ac.uk/teideb/ .
* ant and ant-contrib. Note that as of 2011-11-30, ant-contrib is not availabe as as RedHat package.

== Source code and licensing ==
Freely available.

== Support for TEI ==

== Language(s) ==
Documentation is in English.

== Documentation ==
These two pages should be identical and therefore equally authoritative:

* http://www.tei-c.org/Tools/Stylesheets/
* http://www.tei-c.org/release/doc/tei-xsl-common/

Among the components of this package of stylesheets not documented are the following:

* <code>tools2/oddbyexample.xsl</code> – generates a list of all the attribute values used in the directory of texts you apply it to, in the form of an [[ODD]] file, from which you can in turn generate documentation and schemas using Roma
* <code>tools2/odd2nuodd.xsl</code> – switches from a traditional ODD-by-exclusion to a newer form ODD-by-inclusion

See also this guide by Lauara Mandell, which contains some documentation and some videos: http://idhmc.tamu.edu/chat/xslt/modifyTEI.html

=== Creating a custom profile ===

To create a profile for converting to/from a format and TEI XML, create either or both as needed:

<code>profiles/$PROFILENAME/$FORMAT/to.xsl</code>

<code>profiles/$PROFILENAME/$FORMAT/from.xsl</code>

Start by copying the files in <code>profiles/default/$FORMAT/</code> and then adding your own overrides.

Note that if your <code>$FORMAT</code> is docx, this directory must contain a file <code>template.docx</code> which is used to create .docx files from. See the sample in the default profile.

=== Converting from DOCX format ===

Word has two kinds of styles: paragraph styles and character styles. According to Sebastian, "The basic rule of the conversion is that if named [character] styles are used, they take precedence over manual formatting." That is, if text (even a whole paragraph) has a character style applied but is also marked in Word as being italicized, the italics will not come through in the conversion separate from the character style.

== Tech support ==

== User community ==

== Sample implementations ==

The package includes a number of profiles in the <code>profiles/</code> directory.

== Current version number and date of release ==

6.28 (2013-03-02)

== History of versions ==

See https://sourceforge.net/projects/tei/files/Stylesheets/ .

== How to download or buy ==

If you use [[Oxygen]], the easiest thing to do might be to download as part of [http://code.google.com/p/oxygen-tei/ oxygen-tei], the open-source TEI framework built into <oXygen/>. Otherwise, there are three options:

=== Download zip file ===
Download the latest zip file (below all of the folders) from https://sourceforge.net/projects/tei/files/Stylesheets/ .

=== Install the Debian package ===

Install the <code>tei-xsl</code> Debian package from the [http://tei.oucs.ox.ac.uk/teideb/ list of Debian packages].

=== Get from Subversion ===

<code>
svn co https://tei.svn.sourceforge.net/svnroot/tei/trunk/ /path/to/local/directory/
</code>

Then, if you want to add these to <code>/usr/</code> (which you will need to do in order to use the command-line shell scripts), you can do the following:

<code>
cd /path/to/local/directory/Stylesheets/
</code>

<code>
make install
</code>

but note the following:

* You should not download just the stylesheets module (using <code>svn co https://tei.svn.sourceforge.net/svnroot/tei/trunk/Stylesheets/</code> ) because <code>Stylesheets/Makefile</code> requires that other modules be present.
* You will need to run <code>make install</code> as a user with write permission to <code>/usr/</code> . So if using Ubuntu, for example, you will need to instead do <code>sudo make install</code> .

== Additional notes ==

== Notes ==

<references/>

TEI-emacs

2013-03-13T09:51:27Z

Rahtz: /* Documentation */

[[Category:Tools]]

[[Category:Editing tools]]

== Synopsis ==
An emacs setup for working with TEI files.

== Features ==
The following Emacs packages are also recommended for using with Emacs and TEI XML

* ucs
* nxml-mode
* psgml
* semantic
* speedbar
* tdtd
* xslide
* xslt-process

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

== System requirements ==
Windows or Linux system. Windows users must first install Emacs for Windows.

== Source code and licensing ==
Open source

== Support for TEI ==
TEI and TEI Lite support out of the box

== Language(s) ==
Tool and website in English.

== Documentation ==

== Tech support ==
Sebastian Rahtz welcomes questions and bug reports.

== User community ==

== Current version number and date of release ==

3.11 (March 2013)

== History of versions ==
See https://sourceforge.net/projects/tei/files/tei-emacs/ .

== How to download or buy ==
On Github at https://github.com/sebastianrahtz/tei-emacs.git

Or [http://tei.oucs.ox.ac.uk/teideb/ download the Debian package].

== Additional notes ==

TEI-emacs

2013-03-13T09:50:56Z

Rahtz: /* How to download or buy */

[[Category:Tools]]

[[Category:Editing tools]]

== Synopsis ==
An emacs setup for working with TEI files.

== Features ==
The following Emacs packages are also recommended for using with Emacs and TEI XML

* ucs
* nxml-mode
* psgml
* semantic
* speedbar
* tdtd
* xslide
* xslt-process

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

== System requirements ==
Windows or Linux system. Windows users must first install Emacs for Windows.

== Source code and licensing ==
Open source

== Support for TEI ==
TEI and TEI Lite support out of the box

== Language(s) ==
Tool and website in English.

== Documentation ==
Notes on installation and use are at http://www.tei-c.org.uk/Software/tei-emacs/

== Tech support ==
Sebastian Rahtz welcomes questions and bug reports.

== User community ==

== Current version number and date of release ==

3.11 (March 2013)

== History of versions ==
See https://sourceforge.net/projects/tei/files/tei-emacs/ .

== How to download or buy ==
On Github at https://github.com/sebastianrahtz/tei-emacs.git

Or [http://tei.oucs.ox.ac.uk/teideb/ download the Debian package].

== Additional notes ==