Difference between revisions of "Talk:Best Practices for TEI in Libraries"
(→examples of each encoding level: this is now done) |
(→Test ODDs and schemas derived from them: renamed section, now links to source on GitHub) |
||
Line 1: | Line 1: | ||
The following are revisions to make to the BP before making an official "release". There is a separate list of [[Future changes to Best Practices for TEI in Libraries]]. | The following are revisions to make to the BP before making an official "release". There is a separate list of [[Future changes to Best Practices for TEI in Libraries]]. | ||
− | == | + | == Review ODDs and schemas derived from them == |
− | + | Syd wrote: | |
− | + | <blockquote> | |
− | + | [T]he ODD files themselves are now in a git repository on GitHub. See http://github.com/sydb/TEI-in-Libraries/tree/master. You can view, download, and even edit the files using that web interface. | |
− | |||
− | |||
− | |||
− | |||
− | + | However, I strongly recommend *against* editing them directly via the GitHub interface. From years of experience editing XML files in shared repositories, I can tell you it can really mess up others when you inadvertently commit a change that is not well-formed, which is easier to do than most people think when using a non-XML aware editor. | |
− | + | However, if you are even slightly more adventurous, it is not particularly difficult to use the `git` command to mirror the | |
− | * | + | repository on your local drive, edit and test there, and then commit (and apparently push) when you're done. |
+ | |||
+ | When you sign up on GitHub, please let me know your user name and whether or not you would like to receive <soCalled>pull requests</>, which let you know there has been an update to [ the repository itself or the website copy of it? idunno, but I think the latter ]. Methods of sending info to you are: | ||
+ | |||
+ | * POST to a URL | ||
+ | * Basecamp | ||
+ | * CIA | ||
+ | * Campfire | ||
+ | * Email | ||
+ | * FogBugz | ||
+ | * FriendFeed | ||
+ | * Irc | ||
+ | * Jabber | ||
+ | * Lighthouse | ||
+ | * Presently | ||
+ | * Rubyforge | ||
+ | * Trac | ||
+ | * Twitter | ||
+ | |||
+ | In general in projects like this, the source code (in this case the ODD) is left in the repository, and interested individuals download the source and generate the derived files from it (in this case schemas and HTML or PDF documentation) on their own. To do this you will need to use one of the following: | ||
+ | |||
+ | * roma: very hard to install; but easiest and fastest to use, especially if you write a front-end script; for command-line use only (to my knowledge that means Mac OS X or GNU/Linux only -- I don't think anyone has ported to CygWin or similar) | ||
+ | |||
+ | * Roma: web interface requires no installation and is reasonably intuitive; but takes quite a few clicks, requires a net connection, and may be quite slow if lots of people are using the server at once (which last I knew was under Sebastian's desk in Oxford) | ||
+ | |||
+ | * Vesta: very easy to install[1], pretty intuitive, and runs fast if you have a fast machine; but takes a few clicks, and does not remember your settings between invocations; Mac OS X or GNU/Linux only | ||
+ | </blockquote> | ||
== Pending Review: Use of any P5 attributes == | == Pending Review: Use of any P5 attributes == |
Revision as of 03:19, 20 December 2010
The following are revisions to make to the BP before making an official "release". There is a separate list of Future changes to Best Practices for TEI in Libraries.
Contents
Review ODDs and schemas derived from them
Syd wrote:
[T]he ODD files themselves are now in a git repository on GitHub. See http://github.com/sydb/TEI-in-Libraries/tree/master. You can view, download, and even edit the files using that web interface.
However, I strongly recommend *against* editing them directly via the GitHub interface. From years of experience editing XML files in shared repositories, I can tell you it can really mess up others when you inadvertently commit a change that is not well-formed, which is easier to do than most people think when using a non-XML aware editor.
However, if you are even slightly more adventurous, it is not particularly difficult to use the `git` command to mirror the repository on your local drive, edit and test there, and then commit (and apparently push) when you're done.
When you sign up on GitHub, please let me know your user name and whether or not you would like to receive <soCalled>pull requests</>, which let you know there has been an update to [ the repository itself or the website copy of it? idunno, but I think the latter ]. Methods of sending info to you are:
- POST to a URL
- Basecamp
- CIA
- Campfire
- FogBugz
- FriendFeed
- Irc
- Jabber
- Lighthouse
- Presently
- Rubyforge
- Trac
In general in projects like this, the source code (in this case the ODD) is left in the repository, and interested individuals download the source and generate the derived files from it (in this case schemas and HTML or PDF documentation) on their own. To do this you will need to use one of the following:
- roma: very hard to install; but easiest and fastest to use, especially if you write a front-end script; for command-line use only (to my knowledge that means Mac OS X or GNU/Linux only -- I don't think anyone has ported to CygWin or similar)
- Roma: web interface requires no installation and is reasonably intuitive; but takes quite a few clicks, requires a net connection, and may be quite slow if lots of people are using the server at once (which last I knew was under Sebastian's desk in Oxford)
- Vesta: very easy to install[1], pretty intuitive, and runs fast if you have a fast machine; but takes a few clicks, and does not remember your settings between invocations; Mac OS X or GNU/Linux only
Pending Review: Use of any P5 attributes
On the June 2 conference call, the group agreed to create a list of all attributes to include for Level 1-4.
- Prose changed now reflects that there are recommended/required attributes in the body of a text
- This text will need to be revised again after the attribute list has been generated (2010-09:30: DONE BY KEVIN)
- We will probably add an appendix of all attributes identified (DONE BY MICHELLE IN AUGUST)
- With the goal of creating an "include" list of attributes, Lisa compiled a list of attributes mentioned in the BP, followed by a list of all the additional attributes include in P5, see List of attributes suggested to include in BPG, and those excluded
- The group will need to review the list for completeness
- Syd will constrain the ODDs accordingly
- Group will then need to test against real-life files
Pending Review: Add history of version 3 to Appendix A
Text is now in the main prose. Could benefit from group review.
- I reviewed and think it is good -- I was more out of the loop in 2009, so I am not the best of reviewers. But let this count as my approval! --Emcaulay 13:29, 20 June 2010 (EDT)
Pending Review: Add Tite as Level 3.5
This was strongly recommended by Daniel Pitti in Ann Arbor because he felt certain that administrators and funders would be confused about the difference between TEI Tite and the Best Practices ("don't the libraries already have a TEI customization?"); in fact, Kevin has known this same confusion to arise among TEI Council members. While we have a section of the BP discussion its relationship to Tite, by having a Level 3.5, we can be more explicit about mapping between the two.
Mapping clarification from Kevin: Instead of actually mapping elements, Daniel wanted us to simply proclaim use of Tite as one of a number of appropriate encoding levels for libraries.
Naturally we will not be able to describe Tite the way we do other levels -- by simply saying "all the elements in the previous levels, plus the following". Tite uses different element names of all sorts. There's no point in having Syd make an ODD for Tite since one already exists. So what Kevin envisions here is a sort of "sidebar" about Tite, inserted between Levels 3 and 4 that discusses Tite in a bit more detail than we currently have in the beginning of the BP, with particular discussion of mapping between the two.
We recently had some discussion about the merits of this, so maybe we won't do it in the end. But if we do, we'll need a draft of this new sidebar. Two paragraphs are already written for you (the brief discussion of the relationship between Tite and the BP), and you can pull more information from Tite's discussion of an earlier version of the Best Practices.
Would someone be willing to write a first draft of all of this? Two paragraphs are already written for you, and you can pull more information from Tite's discussion of an earlier version of the Best Practices.
- Can we just use what's written here (rather than link to it) and modify accordingly fpr our level 3.5: http://www.tei-c.org/release/doc/tei-p5-exemplars/html/tei_tite.doc.html#tei-in-lib-bpg. Didn't Kevin write this anyway? If not, whose permission do we need?
- I'm pretty sure Perry Trolard wrote this section. Shouldn't be a problem to use it. However, we should carefully check all the assertions since things have likely changed since Tite was last revised. (kshawkin)
- Kevin looked over changes made since Perry wrote that text in May 2009. Don't see any major changes, so it should be fine to link to Appendix A of Tite. We clarified relation ship between Tite and BP in the prose; adding a Level 3.5 is on hold.
- I'm pretty sure Perry Trolard wrote this section. Shouldn't be a problem to use it. However, we should carefully check all the assertions since things have likely changed since Tite was last revised. (kshawkin)
Add Perry trolard to acks? --Emcaulay 13:32, 20 June 2010 (EDT)
Acknowledgments
- May need to revise DLF thank you to something more onging if they continue ot provide support (under discussion)
examples of each encoding level
We've got one example of Level 1 and one for Level 2 in the Introduction. Kevin has asked Matthew Gibson to provide a Level 3 example. Could we get Level 4 and Level 5 examples? We're looking for examples of texts delivered online, not necessarily with XML exposed. The goal is to show what sort of functionality you might offer at each level, not perfect encoding!
- done (Sept./Oct. 2010)