View source for P6-dev

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 

With the new (as of Nov. 2015) GitHub issue tracker, TEI Council collects P6 issues with the label [https://github.com/TEIC/TEI/labels/postponed%20for%20P6"postponed for p6"]


* 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.
** Would it be an idea to group all elements that describe ''entities'', if a new element ''object'' would be established? By doing this, the dateTime related elements were splitted "naturally".

* Consider placing a restriction on the simultaneous use of @url and @facs on <graphic> (see Council list discussion 2012-06-20). 

NOTE: Some of the work on lists has already been done in release 2.7.0.
* 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)?

* [[Ad-hoc_committee_on_encoding_of_bibliographic_citations#Proposed_future_revisions_to_the_Guidelines_.28which_will_break_backwards_compatibility.29|Things related to encoding of bibliographic citations]]

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

* Expansion of [[ODD#Future_plans:_.22Pure_ODD.22|Pure ODD]] to enable us to define the content model of elements based on context; this would be convertible into models based on complexTypes in XSD, and into Schematron in RelaxNG. This would require that we drop support for DTDs (which most agree would be a good idea anyway).

* Go through a list of recent standards and standards updates and recommend how to use TEI in combination with them. Sample recommendations might be (I'm not asserting the truth of any of these):
** ''If encoders use NISO Z39.84-2005, the DOI may be expected to appear in the  ''idno'' element.''
** ''None of the bibliographic elements exactly match any of the bibliographic elements in ANSI/NISO Z39.96-2012''
** ''If reporting on use digital objects using NISO SUSHI, each object with a TEI header should be reported on''
** ''If linking to resources that are available over both http:// and https:// protocols, it is recommended to use the 'procotol-indepedent' uris starting with // ''
** ...



[[Category:Suggestions]]