TEIWiki - User contributions [en]

Draft minutes of 2010-04 Council meeting

2010-05-11T17:56:41Z

Dpod: /* afternoon of 2010-04-29 */

The following are minutes of the 2010 Council meeting, held April 29-30 in Dublin.

A final version should be added to http://www.tei-c.org/Activities/Council/Meetings/index.xml along with the past meeting minutes.

== morning of 2010-04-29 ==

== afternoon of 2010-04-29 ==

===Presentation of Genetic Workgroup Proposal (EP)===

*3 parts to proposal:
** Sections 1-5: Addition of documentary view of text to main TEI structure
** Sections 6-10: proposals for additions to transcription module
** Genetic encoding

====Discussion====
*** DP pointed out problem that @reason is almost exactly the same as @cause
*** Discussion of whether tei:subst should be able to contain cdata: general reluctance.
*** Issue of @instant: this indicates immediate correction at given stage; values=true|fault
**** DO notes relative rarity of attributes with true|false values in TEI; suggests that it might be better to have a more generic attr for which "instantaneous" is a value as this will allow for the inevitable request for additional values from the community.
** Proposals on Genetic Encoding per se (i.e. stages and the like)
*** This will await the finishing of the collation and apparatus modules
*** Issue with naming of proposed stage elements noted: stageNote, for example, is a well-known type of text structure in theatre.

====Action and Next Steps====
* The council accepts transcription group report in principle, recognising that significant changes may be still necessary
* The council would like to publish the proposal for use by the community, on condition that it is recognised that changes may still be made that break initial material
* The council will break the sections into SF tickets as proposed by Lou (broad terms) and James and Elena (specific items that could be broken off into non-controversial tickets.

===Bibl Report (LR, KH, MH)===

* Most of the council discussion focussed on reviewing the principles proposed by the group.
* Council disagreed with proposal to use examples to suggest good practice (by suppressing examples of alternate coding). It felt it was important to be explicit in the text as well about what was good and bad practice.
* To avoid breaking existing documents (and recognising that bibliographic data can come in a variety of forms, some of which make it necessary to accept less than optimal encodings), we will recommend rather than require the practices suggested by the sub-committee
* The following are tied to the corresponding points in the committee's report
1) The above meta principles apply
2) DITTO
3) Accepted with the exception of name-internal punctuation: e.g. O'Donnell, Smith-Marbles, E. B. White
4) Same as 1: yes subject to meta-conditions.
5) accept
6) [Get Kevin's summary]
7) Leave as is but acknowledge that life is difficult: e.g. you might well have mixed blbstruct and bibls. Leave example.
8) The failure to reflect the proposed values for @type as listed in the guidelines was a bug. But the larger issues about article scope vs. actual citation is more complicated and is to be reexamined by the sub-committee.

Lou and Kevin are to work and implement the easy issues in the odds; sub-committee is to clean up document in light of discussion and return to council with a clean version by June 15, with comments to follow by a deadline to be determined.

== morning of 2010-04-30 ==

=== reports of small-group discussions of feature requests ===

Council members met in groups of two or three to discuss various tickets that were unresolved after yesterday's discussions. Below are notes from reporting back.

[http://sourceforge.net/tracker/?func=detail&aid=2940838&group_id=106328&atid=644065 CALS for TEI (2940838)] – Laurent reported that he, Dan, and Kevin decided on these things to do: (1) add a reference to CALS in the Guidelines as an alternative way to encode tables and (2) use Sebastian's ODD that he developed for CALS as part of his work with ISO [?] to include in the TEI (much like MathML and SVG in the TEI).

Sebastian noted that we actually have a private re-implementation of MathML and SVG by incorporating these from the standard [at the time of ODD generation?]. He also noted that "CALS" can mean many things, not all of which are clearly defined, but most people use it to refer to the CALS exchange model, which is well-specified. He said we need to talk to Norm Walsh [who is our best contact for CALS].

Laurent said the third thing to do is to contact Norm Walsh.

Dan asked Sebastian whether his ODD needs polishing before public distribution. Sebastian replied that ____ and said he just needs a namespace to use for CALS elements.

Lou asked to clarify that there was consensus not to include CALS elements in the Guidelines. Everyone agreed that we would not do so at this time.

[http://sourceforge.net/tracker/?func=detail&aid=2925145&group_id=106328&atid=644065 generic dates (2925145)] – Dot reported that she, Elena, and James discussed a ticket proposing to create att.datable.generic for normalizing dates using non-Gregorian calendars and dating systems. She said they like the idea but are unsure of implementation. James added that the datatype would need to be so loose that it basically becomes free text.

Elena said that ____ would need a new date element.

James said that the ticket proposes a new form of canonical referencing, which Elena noted would need to be defined in the header.

Laurent asked whether we should attempt to rework the proposal or send it back to the author to re-propose in a different form. Dan replied that there's a risk that a new proposal would be less TEI-like.

After a discussion, it was agreed that Elena would summarize the possible ways forward [for the proposer of the ticket]. Lou asked her to monitor the ticket for future discussion and proposals.

[http://sourceforge.net/tracker/index.php?func=detail&aid=2834505&group_id=106328&atid=644065 allow @cert on choice and model.choicePart (2834505)] – Julianne reported that she and Brett discussed this ticket, which included an alternative suggestion in the comment to allow @cert on seg. She and Brett did not like the latter idea, but they also didn't like the original proposal since too many attributes would be allowed on choice and model.choicePart.

Instead, Julianne and Brett proposed to make all elements in model.choicePart members of att.responsibility.

[http://sourceforge.net/tracker/index.php?func=detail&aid=2783323&group_id=106328&atid=644065 allow @to and @from on choice (2783323)] – Julianne reported that she and Brett also discussed this ticket. She said the proposal is in the spirit of the TEI, but she noted that some good alternative encodings were also suggested on the ticket. She said they would like to know what Christian Wittern (who proposed the ticket) thinks of the alternative encodings. She noted that the Guidelines give no examples of @to and @from on app, so it's hard to compare the alternatives.

Dan said that @to and @from are on app because of the possibility of there being a lemma, whereas choice doesn't have these because it doesn't assume the existence of a lemma.

Brett summarized the use case given in the ticket. Elena noted that the proposal provides a simple mechanism for accomplishing something like stand-off markup, but she said it's not clear why we wouldn't allow these attributes on all elements. Laurent and Lou agreed that we need a more generic standoff mechanism and shouldn't create a hack for use only on choice.

Dan noted that, for the use proposed, that there are existing mechanisms (@ref and @key) for pointing to controlled vocabularies and an existing mechanism (app) for encoding a lemma.

[http://sourceforge.net/tracker/index.php?func=detail&aid=2493417&group_id=106328&atid=644065 allowing non-numbers in idnos and alllowing idno in author (2493417)] – Sebastian reported that his group discussed a proposal to allow idno to contain non-numeric identifiers such as URIs and DOIs. His group agreed with this proposal to add idno to model.nameLike.

As for allowing idno in author, the group realized that author already has a content model that appears more flexible than desired (for example, allowing add and del), so they proposed to correct this by changing the content model of author of model.limitedPhrase. Kevin gave a use case for add and del within author: encoding a typewriter manuscript of a draft of a work with a bibliography, where the bibliographic citations are encoded using bibl or biblStruct, in which the author made corrections to author names.

After discussion, consensus was reached to no longer change the content model to model.limitedPhrase but still allow idno in author. Sebastian noted that this will have the side-effect of allowing people to use idno anywhere they might use author (not just within a bibl or biblStruct). He questioned whether we really want to do this. There was discussion.

Lou noted that having idno as a child of author goes against the principle voiced yesterday that elements should describe their parent. Kevin said there are many ways in which markup requires human inference to fully understand it and that this surely is not the only place where a TEI element does not describe the parent.

It was decided to create a separate feature request for ____.

[http://sourceforge.net/tracker/index.php?func=detail&aid=2794512&group_id=106328&atid=644065 space in core module (2794512)] – Dan said the issue is that the example is actually a transcription: the space is important because it appears in the layout not because it has a rhetorical or linguistic meaning--e.g. the leading space in a indented paragraph. So if it is important, you should invoke transcription. The confusion is that gap has two meanings one appropriate to transcription and one appropriate to non-transcription circumstances (such as sampling). Gap was originally omit (sampling) but rename expanded semantically to cover the transcription situation in the move from P2-P3.

We need to indicate in the Guidelines that gap has two distinct meanings: one appropriate strictly to transcription (illegible//missing) and the other (sampling) more generally applicable. We might also want to consider resurrecting P2's omit for the sampling application and say that gap should be used only for transcription (reversing the P3 decision).

Dot said that we want to recommend to David Sewell (the ticket submitter) that he use space (from the transcription module).

[http://# target/targets (****perhaps ticket number 2531384****?)] – Lou reported that there are 8 cases in the Guidelines in which @target takes a single value and 8 others in which it takes 2. Only 4 of these instances have the attribute value defined by an attribute class. His group proposed to introduce an attribute class for all instances of this attribute which would allow 1 to many values. However, the prose of the Guidelines will need to explain that for some elements, it doesn't make sense to have multiple values for @target.

Once this change is made, it will no longer make sense to use the @targets attribute. We will leave this attribute in the Guidelines but discourage its use. The three elements that have the @targets attribute should be added to the new attribute class.

It was also agreed that the discussion of cRef on the ticket should be "spun off" into a different ticket.

=== hyphenation ===

Lou summarized the debate on how to handle encoding of hyphenation.

If you are transcribing early printed books with hyphens at the end of lines, there are a number of ways to do it. If your goal is to transcribe text, including hyphens, faithfully or to encode the text in a way that will allow you to process lexical items (generally speaking, words) without marking up these words with w elements, you will need to represent hyphenation in the source document.

If your encoding will mark line breaks (using lb), this complicates the method for encoding hyphenation and requires any tokenization software to be capable to ignoring elements that can appear within words (like lb). Alternatively, a derived text with lb and other intraword elements removed could be produced for the concordance software from the master encoded text.

In short, the Guidelines are currently not helpful in giving guidance on encoding hyphens that appear to be accidents of line breaks (where a hyphen would not appear in the word had there not been a line break). It has been suggested to use the Unicode soft hyphen character for these cases, and Lou initially thought this would be appropriate; however, Deborah Anderson asked senior Unicode people about this and they told us that use of the soft hyphen for such cases is inappropriate. (The soft hyphen is meant for cases where processing software might choose to break a word, not where it was previously broken.)

So how, then, to indicate on an lb element whether the word was broken across lines? You might use the type attribute to indicate whether a lexical unit has been broken by the hyphen, use whitespace before the element, or use the rend attrbute to describe the hyphenation. Lou suggested using the type attribute to indicate whether the hyphen marks the boundary between lexical items and the rend attribute to describe how this boundary is indicated (using a hyphen, semicolon, etc.). With this method, no hyphen is left as character data in the XML document.

Elena said this is exactly how the Austen project handled hyphenation.

Lou continued that this leaves the problem of handling hyphenation of words across line breaks in languages like Dutch and German, where letters within the word are sometimes duplicated before and after the hyphen. Juliana noted that Old Irish did something similar.

Lou said that it's not clear where to put the lb element and said it would seem you would need to repeat it. Brett suggested a standoff choice element. Elena said that the Austen project used xml:id and corresp. Matthew said that [some project he was involved in] used sameAs with xml:id.

Brett noted that we still haven't given advice on how to handle ambiguous cases (where it's not clear whether the source document's author would have used a hyphen had there not been a line break).

After discussion, it was decided that users could use any of the following values for the rend attribute for cases of ambiguity:

* hyphen
* soft or hard hyphen
* ambiguous
* -

Lou asked whether the Council needs to give advice to ____ or to those revising the Best Practices for TEI in Libraries (both of which had questions about this issue). Kevin said those working on the Best Practices would use the Council decision in order to revise their work.

=== ODD (r)evolutions ===

Sebastian said several tickets have been submitted for problems with and suggestions for the ODD architecture. A mailing list ["tei-meta"] was formed to discuss the future of the ODD system, but there was little discussion. He summarized the desired changes that were detailed in a message to the list on 2010-04-02.

Laurent noted that the proposal for including and excluding elements individually assumes that there's something behind ____ that is pointed to.

There was discussion of the proposed changes.

Dan noted that these changes work best for elements that are in classes but asked how it would affect elements not in classes. There was further discussion, during which Sebastian said that there would need to be a "magic module" -- a TEI module that would automatically select ___.

There was further discussion.

Laurent asked whether we should provide an explicit mechanism to say which ___ [is/are] in the TEI [module?].

There was much further discussion.

Dan and Laurent said we need to have the source [of what?] specify itself to avoid ambiguity. Sebastian disagreed that there's any ambiguity.

Brett asked whether all elements would be included or excluded by default. Sebastian said that currently _____.

There was a discussion on the merits of including or excluding elements as you go while constructing a project-specific schema.

Council agreed to support the the further development of ODD.

Sebastian noted that we will have a problem with combining elements with the same name from different namespaces. Currently, our classes are named after exemplary elements, but it wouldn't be clear which namespace these exemplary elements belong to. He suggested three ways to fix this:

# Change the way model classes are specified in the ODDs. This unfortunately breaks any ODDs currently in use.
# Use namespaces in the names of model classes. This would not be valid RelaxNG, but it's perhaps such a feature could be suggested to the RelaxNG developers.
# Create fake namespaces within the names of model classes, perhaps using the raised dot Unicode character as a delimiter (since it's one of the few characters allowed where needed).

Kevin suggested choosing the first option but adding a feature to Roma that will upgrade any existing ODDs when they are uploaded to use the new system of model classes.

Dan asked whether the first solution still leaves the problem of the third solution. He suggested a fourth solution: adding an attribute (perhaps called "prefix") to the element specification in the ODD language.

After discussion, Council decided that Sebastian will choose the best way to handle homonymous elements from different namespaces. Dan added that he should strive to make ODD mechanisms generalizable beyond the TEI.

== afternoon of 2010-04-30 ==

Editors

2009-12-11T20:02:39Z

Dpod: changed description of OS compat.

This is a comparison table for Editors used for editing TEI.

{| class="wikitable sortable" border="1"
|+Editors for TEI
|-
! Name !! Operating Systems !! GUI Support !! ssh / console support !! Explicit support for XML !! Explicit support for TEI !! URL !!Projects Using !! Beginner-friendliness<br/>(scale 1-10, 1=hard) !! Notes
|-
| vi || all (POSIX-native) || No || Yes || No || No || [http://www.vim.org/] || || 1 ||
|-
| emacs || all (POSIX-native) || Limited || Yes || Yes || No || [http://savannah.gnu.org/projects/emacs/] || [http://www.nzetc.org/ NZETC] || 3 ||
|-
| [[TEIEmacs]] || all (POSIX-native) || Limited || Yes || Yes || Yes || [http://www.tei-c.org.uk/Software/tei-emacs/] || || 3 ||
|-
| jEdit || all (Java) || Yes || No || Yes || Yes || [http://www.jedit.org/] || [http://www.nzetc.org/ NZETC] || 7 ||
|-
| [[OXygen]] || all (Java) || Yes || No || Yes || Yes || [http://www.oxygenxml.com/] || || 8 ||
|-
|}

[[Category:Tools]]
[[Category:Editing tools]]

Editors

2009-12-11T19:52:51Z

Dpod:

This is a comparison table for Editors used for editing TEI.

{| class="wikitable sortable" border="1"
|+Editors for TEI
|-
! Name !! Platforms !! GUI Support !! ssh / console support !! Explicit support for XML !! Explicit support for TEI !! URL !!Projects Using !! Beginner-friendliness<br/>(scale 1-10, 1=hard) !! Notes
|-
| vi || POSIX-native but cross-platform || No || Yes || No || No || [http://www.vim.org/] || || 1 ||
|-
| emacs || POSIX-native but cross-platform || Limited || Yes || Yes || No || [http://savannah.gnu.org/projects/emacs/] || [http://www.nzetc.org/ NZETC] || 3 ||
|-
| [[TEIEmacs]] || POSIX-native but cross-platform || Limited || Yes || Yes || Yes || [http://www.tei-c.org.uk/Software/tei-emacs/] || || 3 ||
|-
| jEdit || Java / cross-platform || Yes || No || Yes || Yes || [http://www.jedit.org/] || [http://www.nzetc.org/ NZETC] || 7 ||
|-
| [[OXygen]] || Java / cross-platform || Yes || No || Yes || Yes || [http://www.oxygenxml.com/] || || 8 ||
|-
|}

[[Category:Tools]]
[[Category:Editing tools]]

Editors

2009-12-11T19:52:31Z

Dpod:

This is a comparison table for Editors used for editing TEI.

{| class="wikitable sortable" border="1"
|+Editors for TEI
|-
! Name !! Platforms !! GUI Support !! ssh / console support !! Explicit support for XML !! Explicit support for TEI !! URL !!Projects Using !! Beginner-friendliness (scale 1-10, 1=hard) !! Notes
|-
| vi || POSIX-native but cross-platform || No || Yes || No || No || [http://www.vim.org/] || || 1 ||
|-
| emacs || POSIX-native but cross-platform || Limited || Yes || Yes || No || [http://savannah.gnu.org/projects/emacs/] || [http://www.nzetc.org/ NZETC] || 3 ||
|-
| [[TEIEmacs]] || POSIX-native but cross-platform || Limited || Yes || Yes || Yes || [http://www.tei-c.org.uk/Software/tei-emacs/] || || 3 ||
|-
| jEdit || Java / cross-platform || Yes || No || Yes || Yes || [http://www.jedit.org/] || [http://www.nzetc.org/ NZETC] || 7 ||
|-
| [[OXygen]] || Java / cross-platform || Yes || No || Yes || Yes || [http://www.oxygenxml.com/] || || 8 ||
|-
|}

[[Category:Tools]]
[[Category:Editing tools]]

GuidelinesFormattingSuggestions

2007-07-17T14:13:19Z

Dpod: /* Suggestions for HTML Version of TEI Guidelines */

This is just a page to collect suggestions for changes to the formatting of the TEI Guidelines.

'''Note:''' These should be suggestions for formatting the TEI Guidelines themselves, not the TEI Website.

== Suggestions for HTML Version of TEI Guidelines ==

# Tidying up of the way module descriptions are integrated into the body of the Guidelines.
# Given how many chapters there are, would it be a good idea to have a drop-down menu for the Table of Contents? Or could we fit however many chapter numbers it is in tabs across the top? (Website Issue?)
# Sometimes (like right now) Appendix B: Elements, shows the full content of the element description rather than just a list of element names linked to the discussion. I prefer the list of names with links approach. (Agreed, Website Issue?)
# At the bottom of each page, we have a lower case "edited by..." it should be upper case.
# <del>DONE</del> With styles off, the presentation of paragraphs is bad, because they are these odd <nowiki><div class="p"></nowiki> constructions. Why aren't they html:p? The tei <--> html p conversion problem was more or less solved, I thought? // <del>Seems indeed to be fixed now</del> Spoke too soon: look at the code for the third paragraph in 15.2.3 (including examples).
# The navbar if it stays should go on the other side: it should also be relatively width'ed, since you can break it if you crank the text size up. (Website Issue?)
# First line highlighted when moused over
# DONE <del> <nowiki><foreign xml:lang="LA"></nowiki> is not output as italics e.g.<nowiki><foreign xml:lang="LA">scriptio continua</foreign></nowiki> </del>
# DONE <del><nowiki><mentioned> (e.g."<mentioned>poem</mentioned>, <mentioned>title</mentioned">) is not
rendered, but probably this doesn't need to be changed</nowiki></del>
# The image at http://www.tei-c.org/release/doc/tei-p5-doc/html/SG.html#SG152 is not really well visible even if it comes out nicely once printed
# Space is output before <nowiki><gi>prt</gi> e.g. <ptr target="#SG17"/></nowiki>
# Better styling of XML examples which are given as CDATA since they aren't TEI elements
# Better styling of all Relax NG examples.
# It would be good if attributes could be not only indented as they are now, visualised better or rendered differently from the main text when inserted in the explanation e.g. <nowiki><specDesc key="head" atts="type"/></nowiki>
# Sometimes chapter names not output as in note on http://tei.oucs.ox.ac.uk/Query/tag.xq?name=att.declaring
# The Appendix E Index: There are an extra line between each entry with an underline which looks odd. And the links does not work here. And I do not quite get by which criteria these index words are selected. And is a one column list the best way to present this? Should there be a paragraph at the top to say that this is?
# DONE <del>Why are all the notes shown at the front page http://www.tei-c.org/release/doc/tei-p5-doc/html/index.html ? And should it be possible to click on a note to go to the text where the note belongs? </del>
# What is the purpose of "Skip links" (at to of the menu to the left)? (Website Issue?)
# The layout of the the entry for each element, macro or classes are different from the rest of the guidelines. Should it be more of the same? For instance is the menu to the left not available. On the other hand I think there should be a distinction between these two parts.
# The "Up: Contents" at the bottom of the pages, brings you the index page of the guidelines, so maybe it should be called "Up: Front page" of something in that direction. Or should it just go to the top of the page? Need a new name in that case as well. The middle option in the read text at the bottom "TEI Consortium | TEI P5 | Feedback" also brings you to the index page, which is an other argument to make the "Up: Contents" into "Up: Top" or something.
# DONE <del>Documentation for elements should show the allowed parents for each element (i.e. contexts in which the element can appear). This used to be in the P4 docs but isn't in the P5.</del>
# DONE <del>'''egXML''' markup should be styled such that angle brackets, element and attribute names, attribute values, namespace prefixes, etc, are all distinctly coloured. Lots of browsers have something like for providing a default rendition of XML documents which don't have their own <?xml-stylesheet?> processing instruction. Some of these have + and - things so you can open and collapse elements, which I think we should do without, and I also know Firefox's one omits namespace prefixes on elements, which is just crazy. I have some XSLT code to do XML syntax highlighting hanging around somewhere as part of a Schematron report, I think; I will track it down if you like.</del>
# DONE <del>Footnotes should be hyperlinked in both directions - i.e. from the reference marker to the note, and from the note back to the reference marker.</del>
# DONE <del>Change the rendition of tei:ref; it's currently broken:<nowiki> <a target="#FS" class="link_ptr" href="FS.html" title="16">12 Feature Structures</a>.</nowiki></del>
## DONE <del>Target attribute should not be used (it currently has invalid data type anyway - it's not supposed to be a URI).</del>
## DONE <del>Title attribute should be meaningful - "16" is hopeless as a title. Hyperlinks from footnote references could usefully include a truncated version of the note body as the title attribute. I've done this at www.nzetc.org (e.g. at http://www.nzetc.org/tm/scholarly/tei-WarEarl-t1-body-d5.html#reference-to-fn1-54 - hover your mouse over the asterisk reference mark ). I've found this is quite useful - sometimes it's not necessary to actually click the footnote reference at all but just hover over it. e.g. <a href="#Note61" title="The BibTeX scheme is intentionally compatible with that of Scribe, although it omits some fields used by Scribe. Hence only one list of fields is given here.">61</a>. (Poss. Problem: title tooltips cropped in some browsers if too long.)</del>
# html/head/link elements should be provided to navigate the guidelines (i.e. next and previous, toc, glossary, whatever).
# Headings should have bookmarkable self-referential hyperlinks attached, like you sometimes see on blogs. This is convenient for bookmarking a point in the guidelines. e.g. instead of: <nowiki> <div class="div3" id="PHCO"><h4>14.1.1 Use of Core Tags for Transcriptional Work</h4>...</div> You would have: <div class="div3" id="PHCO"><h4><a href="#PHCO" class="permalink">14.1.1 Use of Core Tags for Transcriptional Work</a></h4><...</div> I've also seen (though I don't know the best HTML/CSS source for it) a technique where a very faint ¶ appears after the heading, which gets darker when you hover over it, and works as a link to the current section. Maybe something like this?:<div class="div3" id="PHCO"><h4>14.1.1 Use of Core Tags for Transcriptional Work <a href="#PHCO" class="permalink">¶</a></h4><...</div> </nowiki>
# Get rid of the sidebar or make it configurable (But: "where would you put the table of contents?")(Answer:"I would think you could use breadcrumbs for the uplink back to a full toc and have only the toc for the chapter itself at the beginning of the text.")
# Have a "print view" (In addition to the PDF, a most-formatting-stripped view without layout structure)
# DONE <del>Show possible parents of elements in the reference chapter</del>
# Show possible children of elements in the reference chapter
# Tidy up the display of rng fragments and make the display (and print!) of these passages optional (i.e. When printing, they seem to run occasionally over the edge of the page. Thinking of it, the same also happens to the examples here and there.) (Answer: "both the schema fragments and examples are pretty-printing. and the algorithm obviously needs more tweaking.") (Appears to be browser dependent, needs more thought).
# The rnc rng toggle works great, but I wonder if we shouldn't indicate which version you are looking at when you are looking at the actual code: an <nowiki><h3></nowiki> or something at the beginning of the fragment saying "RNG:" or "RNC:" as appropriate would be enough. Currently the button shows the other schema name (because of course it is what you are supposed to click on to get to it). Perhaps that button could be clarified to: "Switch to RNC" etc.
# The element description in the Element appendix is not part of the table showing the other information about the element. I think this might cause people to miss it. I'd recommend adding it as a first row: <nowiki><td>Description:</td><td></td></nowiki>

== Suggestions for PDF Version of TEI Guidelines ==

# No suggestions specifically received so far, except some which carry over from HTML formatting (i.e. that element references should show possible children, etc.)

GuidelinesFormattingSuggestions

2007-07-17T14:02:39Z

Dpod: /* Suggestions for HTML Version of TEI Guidelines */

This is just a page to collect suggestions for changes to the formatting of the TEI Guidelines.

'''Note:''' These should be suggestions for formatting the TEI Guidelines themselves, not the TEI Website.

== Suggestions for HTML Version of TEI Guidelines ==

# Tidying up of the way module descriptions are integrated into the body of the Guidelines.
# Given how many chapters there are, would it be a good idea to have a drop-down menu for the Table of Contents? Or could we fit however many chapter numbers it is in tabs across the top? (Website Issue?)
# Sometimes (like right now) Appendix B: Elements, shows the full content of the element description rather than just a list of element names linked to the discussion. I prefer the list of names with links approach. (Agreed, Website Issue?)
# At the bottom of each page, we have a lower case "edited by..." it should be upper case.
# DONE <del>With styles off, the presentation of paragraphs is bad, because they are these odd <nowiki><div class="p"></nowiki> constructions. Why aren't they html:p? The tei <--> html p conversion problem was more or less solved, I thought?</del> // Seems indeed to be fixed now
# The navbar if it stays should go on the other side: it should also be relatively width'ed, since you can break it if you crank the text size up. (Website Issue?)
# First line highlighted when moused over
# DONE <del> <nowiki><foreign xml:lang="LA"></nowiki> is not output as italics e.g.<nowiki><foreign xml:lang="LA">scriptio continua</foreign></nowiki> </del>
# DONE <del><nowiki><mentioned> (e.g."<mentioned>poem</mentioned>, <mentioned>title</mentioned">) is not
rendered, but probably this doesn't need to be changed</nowiki></del>
# The image at http://www.tei-c.org/release/doc/tei-p5-doc/html/SG.html#SG152 is not really well visible even if it comes out nicely once printed
# Space is output before <nowiki><gi>prt</gi> e.g. <ptr target="#SG17"/></nowiki>
# Better styling of XML examples which are given as CDATA since they aren't TEI elements
# Better styling of all Relax NG examples.
# It would be good if attributes could be not only indented as they are now, visualised better or rendered differently from the main text when inserted in the explanation e.g. <nowiki><specDesc key="head" atts="type"/></nowiki>
# Sometimes chapter names not output as in note on http://tei.oucs.ox.ac.uk/Query/tag.xq?name=att.declaring
# The Appendix E Index: There are an extra line between each entry with an underline which looks odd. And the links does not work here. And I do not quite get by which criteria these index words are selected. And is a one column list the best way to present this? Should there be a paragraph at the top to say that this is?
# DONE <del>Why are all the notes shown at the front page http://www.tei-c.org/release/doc/tei-p5-doc/html/index.html ? And should it be possible to click on a note to go to the text where the note belongs? </del>
# What is the purpose of "Skip links" (at to of the menu to the left)? (Website Issue?)
# The layout of the the entry for each element, macro or classes are different from the rest of the guidelines. Should it be more of the same? For instance is the menu to the left not available. On the other hand I think there should be a distinction between these two parts.
# The "Up: Contents" at the bottom of the pages, brings you the index page of the guidelines, so maybe it should be called "Up: Front page" of something in that direction. Or should it just go to the top of the page? Need a new name in that case as well. The middle option in the read text at the bottom "TEI Consortium | TEI P5 | Feedback" also brings you to the index page, which is an other argument to make the "Up: Contents" into "Up: Top" or something.
# DONE <del>Documentation for elements should show the allowed parents for each element (i.e. contexts in which the element can appear). This used to be in the P4 docs but isn't in the P5.</del>
# DONE <del>'''egXML''' markup should be styled such that angle brackets, element and attribute names, attribute values, namespace prefixes, etc, are all distinctly coloured. Lots of browsers have something like for providing a default rendition of XML documents which don't have their own <?xml-stylesheet?> processing instruction. Some of these have + and - things so you can open and collapse elements, which I think we should do without, and I also know Firefox's one omits namespace prefixes on elements, which is just crazy. I have some XSLT code to do XML syntax highlighting hanging around somewhere as part of a Schematron report, I think; I will track it down if you like.</del>
# DONE <del>Footnotes should be hyperlinked in both directions - i.e. from the reference marker to the note, and from the note back to the reference marker.</del>
# DONE <del>Change the rendition of tei:ref; it's currently broken:<nowiki> <a target="#FS" class="link_ptr" href="FS.html" title="16">12 Feature Structures</a>.</nowiki></del>
## DONE <del>Target attribute should not be used (it currently has invalid data type anyway - it's not supposed to be a URI).</del>
## DONE <del>Title attribute should be meaningful - "16" is hopeless as a title. Hyperlinks from footnote references could usefully include a truncated version of the note body as the title attribute. I've done this at www.nzetc.org (e.g. at http://www.nzetc.org/tm/scholarly/tei-WarEarl-t1-body-d5.html#reference-to-fn1-54 - hover your mouse over the asterisk reference mark ). I've found this is quite useful - sometimes it's not necessary to actually click the footnote reference at all but just hover over it. e.g. <a href="#Note61" title="The BibTeX scheme is intentionally compatible with that of Scribe, although it omits some fields used by Scribe. Hence only one list of fields is given here.">61</a>. (Poss. Problem: title tooltips cropped in some browsers if too long.)</del>
# html/head/link elements should be provided to navigate the guidelines (i.e. next and previous, toc, glossary, whatever).
# Headings should have bookmarkable self-referential hyperlinks attached, like you sometimes see on blogs. This is convenient for bookmarking a point in the guidelines. e.g. instead of: <nowiki> <div class="div3" id="PHCO"><h4>14.1.1 Use of Core Tags for Transcriptional Work</h4>...</div> You would have: <div class="div3" id="PHCO"><h4><a href="#PHCO" class="permalink">14.1.1 Use of Core Tags for Transcriptional Work</a></h4><...</div> I've also seen (though I don't know the best HTML/CSS source for it) a technique where a very faint ¶ appears after the heading, which gets darker when you hover over it, and works as a link to the current section. Maybe something like this?:<div class="div3" id="PHCO"><h4>14.1.1 Use of Core Tags for Transcriptional Work <a href="#PHCO" class="permalink">¶</a></h4><...</div> </nowiki>
# Get rid of the sidebar or make it configurable (But: "where would you put the table of contents?")(Answer:"I would think you could use breadcrumbs for the uplink back to a full toc and have only the toc for the chapter itself at the beginning of the text.")
# Have a "print view" (In addition to the PDF, a most-formatting-stripped view without layout structure)
# DONE <del>Show possible parents of elements in the reference chapter</del>
# Show possible children of elements in the reference chapter
# Tidy up the display of rng fragments and make the display (and print!) of these passages optional (i.e. When printing, they seem to run occasionally over the edge of the page. Thinking of it, the same also happens to the examples here and there.) (Answer: "both the schema fragments and examples are pretty-printing. and the algorithm obviously needs more tweaking.") (Appears to be browser dependent, needs more thought).
# The rnc rng toggle works great, but I wonder if we shouldn't indicate which version you are looking at when you are looking at the actual code: an <nowiki><h3></nowiki> or something at the beginning of the fragment saying "RNG:" or "RNC:" as appropriate would be enough. Currently the button shows the other schema name (because of course it is what you are supposed to click on to get to it). Perhaps that button could be clarified to: "Switch to RNC" etc.
# The element description in the Element appendix is not part of the table showing the other information about the element. I think this might cause people to miss it. I'd recommend adding it as a first row: <nowiki><td>Description:</td><td></td></nowiki>

== Suggestions for PDF Version of TEI Guidelines ==

# No suggestions specifically received so far, except some which carry over from HTML formatting (i.e. that element references should show possible children, etc.)

GuidelinesFormattingSuggestions

2007-07-17T13:55:36Z

Dpod: /* Suggestions for HTML Version of TEI Guidelines */

This is just a page to collect suggestions for changes to the formatting of the TEI Guidelines.

'''Note:''' These should be suggestions for formatting the TEI Guidelines themselves, not the TEI Website.

== Suggestions for HTML Version of TEI Guidelines ==

# Tidying up of the way module descriptions are integrated into the body of the Guidelines.
# Given how many chapters there are, would it be a good idea to have a drop-down menu for the Table of Contents? Or could we fit however many chapter numbers it is in tabs across the top? (Website Issue?)
# Sometimes (like right now) Appendix B: Elements, shows the full content of the element description rather than just a list of element names linked to the discussion. I prefer the list of names with links approach. (Agreed, Website Issue?)
# At the bottom of each page, we have a lower case "edited by..." it should be upper case.
# DONE <del>With styles off, the presentation of paragraphs is bad, because they are these odd <nowiki><div class="p"></nowiki> constructions. Why aren't they html:p? The tei <--> html p conversion problem was more or less solved, I thought?</del> // Seems indeed to be fixed now
# The navbar if it stays should go on the other side: it should also be relatively width'ed, since you can break it if you crank the text size up. (Website Issue?)
# First line highlighted when moused over
# DONE <del> <nowiki><foreign xml:lang="LA"></nowiki> is not output as italics e.g.<nowiki><foreign xml:lang="LA">scriptio continua</foreign></nowiki> </del>
# DONE <del><nowiki><mentioned> (e.g."<mentioned>poem</mentioned>, <mentioned>title</mentioned">) is not
rendered, but probably this doesn't need to be changed</nowiki></del>
# The image at http://www.tei-c.org/release/doc/tei-p5-doc/html/SG.html#SG152 is not really well visible even if it comes out nicely once printed
# Space is output before <nowiki><gi>prt</gi> e.g. <ptr target="#SG17"/></nowiki>
# Better styling of XML examples which are given as CDATA since they aren't TEI elements
# Better styling of all Relax NG examples.
# It would be good if attributes could be not only indented as they are now, visualised better or rendered differently from the main text when inserted in the explanation e.g. <nowiki><specDesc key="head" atts="type"/></nowiki>
# Sometimes chapter names not output as in note on http://tei.oucs.ox.ac.uk/Query/tag.xq?name=att.declaring
# The Appendix E Index: There are an extra line between each entry with an underline which looks odd. And the links does not work here. And I do not quite get by which criteria these index words are selected. And is a one column list the best way to present this? Should there be a paragraph at the top to say that this is?
# DONE <del>Why are all the notes shown at the front page http://www.tei-c.org/release/doc/tei-p5-doc/html/index.html ? And should it be possible to click on a note to go to the text where the note belongs? </del>
# What is the purpose of "Skip links" (at to of the menu to the left)? (Website Issue?)
# The layout of the the entry for each element, macro or classes are different from the rest of the guidelines. Should it be more of the same? For instance is the menu to the left not available. On the other hand I think there should be a distinction between these two parts.
# The "Up: Contents" at the bottom of the pages, brings you the index page of the guidelines, so maybe it should be called "Up: Front page" of something in that direction. Or should it just go to the top of the page? Need a new name in that case as well. The middle option in the read text at the bottom "TEI Consortium | TEI P5 | Feedback" also brings you to the index page, which is an other argument to make the "Up: Contents" into "Up: Top" or something.
# DONE <del>Documentation for elements should show the allowed parents for each element (i.e. contexts in which the element can appear). This used to be in the P4 docs but isn't in the P5.</del>
# DONE <del>'''egXML''' markup should be styled such that angle brackets, element and attribute names, attribute values, namespace prefixes, etc, are all distinctly coloured. Lots of browsers have something like for providing a default rendition of XML documents which don't have their own <?xml-stylesheet?> processing instruction. Some of these have + and - things so you can open and collapse elements, which I think we should do without, and I also know Firefox's one omits namespace prefixes on elements, which is just crazy. I have some XSLT code to do XML syntax highlighting hanging around somewhere as part of a Schematron report, I think; I will track it down if you like.</del>
# DONE <del>Footnotes should be hyperlinked in both directions - i.e. from the reference marker to the note, and from the note back to the reference marker.</del>
# DONE <del>Change the rendition of tei:ref; it's currently broken:<nowiki> <a target="#FS" class="link_ptr" href="FS.html" title="16">12 Feature Structures</a>.</nowiki></del>
## DONE <del>Target attribute should not be used (it currently has invalid data type anyway - it's not supposed to be a URI).</del>
## DONE <del>Title attribute should be meaningful - "16" is hopeless as a title. Hyperlinks from footnote references could usefully include a truncated version of the note body as the title attribute. I've done this at www.nzetc.org (e.g. at http://www.nzetc.org/tm/scholarly/tei-WarEarl-t1-body-d5.html#reference-to-fn1-54 - hover your mouse over the asterisk reference mark ). I've found this is quite useful - sometimes it's not necessary to actually click the footnote reference at all but just hover over it. e.g. <a href="#Note61" title="The BibTeX scheme is intentionally compatible with that of Scribe, although it omits some fields used by Scribe. Hence only one list of fields is given here.">61</a>. (Poss. Problem: title tooltips cropped in some browsers if too long.)</del>
# html/head/link elements should be provided to navigate the guidelines (i.e. next and previous, toc, glossary, whatever).
# Headings should have bookmarkable self-referential hyperlinks attached, like you sometimes see on blogs. This is convenient for bookmarking a point in the guidelines. e.g. instead of: <nowiki> <div class="div3" id="PHCO"><h4>14.1.1 Use of Core Tags for Transcriptional Work</h4>...</div> You would have: <div class="div3" id="PHCO"><h4><a href="#PHCO" class="permalink">14.1.1 Use of Core Tags for Transcriptional Work</a></h4><...</div> I've also seen (though I don't know the best HTML/CSS source for it) a technique where a very faint ¶ appears after the heading, which gets darker when you hover over it, and works as a link to the current section. Maybe something like this?:<div class="div3" id="PHCO"><h4>14.1.1 Use of Core Tags for Transcriptional Work <a href="#PHCO" class="permalink">¶</a></h4><...</div> </nowiki>
# Get rid of the sidebar or make it configurable (But: "where would you put the table of contents?")(Answer:"I would think you could use breadcrumbs for the uplink back to a full toc and have only the toc for the chapter itself at the beginning of the text.")
# Have a "print view" (In addition to the PDF, a most-formatting-stripped view without layout structure)
# DONE <del>Show possible parents of elements in the reference chapter</del>
# Show possible children of elements in the reference chapter
# Tidy up the display of rng fragments and make the display (and print!) of these passages optional (i.e. When printing, they seem to run occasionally over the edge of the page. Thinking of it, the same also happens to the examples here and there.) (Answer: "both the schema fragments and examples are pretty-printing. and the algorithm obviously needs more tweaking.") (Appears to be browser dependent, needs more thought).

== Suggestions for PDF Version of TEI Guidelines ==

# No suggestions specifically received so far, except some which carry over from HTML formatting (i.e. that element references should show possible children, etc.)

GuidelinesFormattingSuggestions

2007-07-17T13:54:55Z

Dpod: /* Suggestions for HTML Version of TEI Guidelines */

This is just a page to collect suggestions for changes to the formatting of the TEI Guidelines.

'''Note:''' These should be suggestions for formatting the TEI Guidelines themselves, not the TEI Website.

== Suggestions for HTML Version of TEI Guidelines ==

# Tidying up of the way module descriptions are integrated into the body of the Guidelines.
# Given how many chapters there are, would it be a good idea to have a drop-down menu for the Table of Contents? Or could we fit however many chapter numbers it is in tabs across the top? (Website Issue?)
# Sometimes (like right now) Appendix B: Elements, shows the full content of the element description rather than just a list of element names linked to the discussion. I prefer the list of names with links approach. (Agreed, Website Issue?)
# At the bottom of each page, we have a lower case "edited by..." it should be upper case.
# DONE <del>With styles off, the presentation of paragraphs is bad, because they are these odd <div class="p"> constructions. Why aren't they html:p? The tei <--> html p conversion problem was more or less solved, I thought?</del> // Seems indeed to be fixed now
# The navbar if it stays should go on the other side: it should also be relatively width'ed, since you can break it if you crank the text size up. (Website Issue?)
# First line highlighted when moused over
# DONE <del> <nowiki><foreign xml:lang="LA"></nowiki> is not output as italics e.g.<nowiki><foreign xml:lang="LA">scriptio continua</foreign></nowiki> </del>
# DONE <del><nowiki><mentioned> (e.g."<mentioned>poem</mentioned>, <mentioned>title</mentioned">) is not
rendered, but probably this doesn't need to be changed</nowiki></del>
# The image at http://www.tei-c.org/release/doc/tei-p5-doc/html/SG.html#SG152 is not really well visible even if it comes out nicely once printed
# Space is output before <nowiki><gi>prt</gi> e.g. <ptr target="#SG17"/></nowiki>
# Better styling of XML examples which are given as CDATA since they aren't TEI elements
# Better styling of all Relax NG examples.
# It would be good if attributes could be not only indented as they are now, visualised better or rendered differently from the main text when inserted in the explanation e.g. <nowiki><specDesc key="head" atts="type"/></nowiki>
# Sometimes chapter names not output as in note on http://tei.oucs.ox.ac.uk/Query/tag.xq?name=att.declaring
# The Appendix E Index: There are an extra line between each entry with an underline which looks odd. And the links does not work here. And I do not quite get by which criteria these index words are selected. And is a one column list the best way to present this? Should there be a paragraph at the top to say that this is?
# DONE <del>Why are all the notes shown at the front page http://www.tei-c.org/release/doc/tei-p5-doc/html/index.html ? And should it be possible to click on a note to go to the text where the note belongs? </del>
# What is the purpose of "Skip links" (at to of the menu to the left)? (Website Issue?)
# The layout of the the entry for each element, macro or classes are different from the rest of the guidelines. Should it be more of the same? For instance is the menu to the left not available. On the other hand I think there should be a distinction between these two parts.
# The "Up: Contents" at the bottom of the pages, brings you the index page of the guidelines, so maybe it should be called "Up: Front page" of something in that direction. Or should it just go to the top of the page? Need a new name in that case as well. The middle option in the read text at the bottom "TEI Consortium | TEI P5 | Feedback" also brings you to the index page, which is an other argument to make the "Up: Contents" into "Up: Top" or something.
# DONE <del>Documentation for elements should show the allowed parents for each element (i.e. contexts in which the element can appear). This used to be in the P4 docs but isn't in the P5.</del>
# DONE <del>'''egXML''' markup should be styled such that angle brackets, element and attribute names, attribute values, namespace prefixes, etc, are all distinctly coloured. Lots of browsers have something like for providing a default rendition of XML documents which don't have their own <?xml-stylesheet?> processing instruction. Some of these have + and - things so you can open and collapse elements, which I think we should do without, and I also know Firefox's one omits namespace prefixes on elements, which is just crazy. I have some XSLT code to do XML syntax highlighting hanging around somewhere as part of a Schematron report, I think; I will track it down if you like.</del>
# DONE <del>Footnotes should be hyperlinked in both directions - i.e. from the reference marker to the note, and from the note back to the reference marker.</del>
# DONE <del>Change the rendition of tei:ref; it's currently broken:<nowiki> <a target="#FS" class="link_ptr" href="FS.html" title="16">12 Feature Structures</a>.</nowiki></del>
## DONE <del>Target attribute should not be used (it currently has invalid data type anyway - it's not supposed to be a URI).</del>
## DONE <del>Title attribute should be meaningful - "16" is hopeless as a title. Hyperlinks from footnote references could usefully include a truncated version of the note body as the title attribute. I've done this at www.nzetc.org (e.g. at http://www.nzetc.org/tm/scholarly/tei-WarEarl-t1-body-d5.html#reference-to-fn1-54 - hover your mouse over the asterisk reference mark ). I've found this is quite useful - sometimes it's not necessary to actually click the footnote reference at all but just hover over it. e.g. <a href="#Note61" title="The BibTeX scheme is intentionally compatible with that of Scribe, although it omits some fields used by Scribe. Hence only one list of fields is given here.">61</a>. (Poss. Problem: title tooltips cropped in some browsers if too long.)</del>
# html/head/link elements should be provided to navigate the guidelines (i.e. next and previous, toc, glossary, whatever).
# Headings should have bookmarkable self-referential hyperlinks attached, like you sometimes see on blogs. This is convenient for bookmarking a point in the guidelines. e.g. instead of: <nowiki> <div class="div3" id="PHCO"><h4>14.1.1 Use of Core Tags for Transcriptional Work</h4>...</div> You would have: <div class="div3" id="PHCO"><h4><a href="#PHCO" class="permalink">14.1.1 Use of Core Tags for Transcriptional Work</a></h4><...</div> I've also seen (though I don't know the best HTML/CSS source for it) a technique where a very faint ¶ appears after the heading, which gets darker when you hover over it, and works as a link to the current section. Maybe something like this?:<div class="div3" id="PHCO"><h4>14.1.1 Use of Core Tags for Transcriptional Work <a href="#PHCO" class="permalink">¶</a></h4><...</div> </nowiki>
# Get rid of the sidebar or make it configurable (But: "where would you put the table of contents?")(Answer:"I would think you could use breadcrumbs for the uplink back to a full toc and have only the toc for the chapter itself at the beginning of the text.")
# Have a "print view" (In addition to the PDF, a most-formatting-stripped view without layout structure)
# DONE <del>Show possible parents of elements in the reference chapter</del>
# Show possible children of elements in the reference chapter
# Tidy up the display of rng fragments and make the display (and print!) of these passages optional (i.e. When printing, they seem to run occasionally over the edge of the page. Thinking of it, the same also happens to the examples here and there.) (Answer: "both the schema fragments and examples are pretty-printing. and the algorithm obviously needs more tweaking.") (Appears to be browser dependent, needs more thought).

== Suggestions for PDF Version of TEI Guidelines ==

# No suggestions specifically received so far, except some which carry over from HTML formatting (i.e. that element references should show possible children, etc.)