This page is a place to record ideas which people feel are not appropriate for addition to the TEI P5 Guidelines (perhaps because they break backwards compatibility so extremely) but which they think should be recorded for reconsideration during development of the next major revision of P6. Things here should probably have had a FR submitted on sourceforge first and been turned down for P5. One when we should be thinking about P6 see the final paragraph of the Birnbaum Doctrine: http://www.tei-c.org/Activities/Council/Working/tcw09.xml
- Module fragmentation, e.g. http://purl.org/tei/fr/3490054 asked for splitting off all dateTime related elements into a small module of its own. Ann Arbor 2012 face to face meeting decided this kind of fragmentation should be postponed until P6.
- Consider placing a restriction on the simultaneous use of @url and @facs on <graphic> (see Council list discussion 2012-06-20).
- Completely redo handling of lists by:
- dropping @type
- introducing @ordered in case the creator of a TEI document wants to record the semantic order of items in the list (but does anyone want to do this? on other elements as well?)
- using only @rend or @style (pending http://purl.org/TEI/FR/3519866 ) to record bulleted, arabic numbers, roman numerals, etc.
- redefining handling of "gloss lists"
- Consider a proper object-oriented inheritance structure, whereby (for instance) there could be a generic "entity" object, with a core structure, and "person", "place" and "org" objects could inherit this structure from it. Inheritance would allow overriding of various components of the structure, and specialization of them; for instance, the generic entity might have a start date and an end date, and for the descendant person would refine these into birth and death. We'd have to consider whether multiple inheritance would be practical (for instance, how would you merge the content models of two ancestors)?
- An object inheritance model
- A firm distinction between elements used in the header and those used in the text. For example:
- There would be one element, with specific attributes and a specific content model, for the title in the metadata and another for any title transcribed in the document)
- att.global might be separated into a class for attributes on header elements and those on text elements.
- A clear distinction between elements used when transcribing a source document (like bibl) and elements used in creating born-digital documents (like biblStruct and biblFull). Need to figure out how msDesc fits into this.