Third party conventions

Besides officially recommended practice, while there are no official means of indicating within a TEI document a particular schema, etc. used by a TEI document (besides a clue given by <TEI>'s @version), third party conventions might be used to suggest customizations for certain domains or purposes (e.g., for an already TEI conformant document, a customization might indicate the expansion of TEI suggested optional attribute values (or constrain them in cases where no suggested values already exist)).

I have started the page here for any who wish to list their conventions. Please realize that these should not be construed as being officially endorsed, since TEI has already decided not to endorse even any specific method of association of such conventions. They are simply presented here in the event others in the community might wish to coalesce around a particular (unofficial) convention. Please place the line [[Category:Third party conventions]] at the beginning or the end of your article, in order to categorise it properly.

Association methods

While there are no official means for indicating which schema a particular TEI document follows, exactly how it could or should be done for one convention (or even a community consensus on how it could be done for most conventions) might be discussed here.

Processing instructions

XML provides the processing instruction ( <? ?> ) which might be used as the means of accomplishing this, given that it does not break conformance and can be safely ignored by TEI conformant processors, regardless of whether they enforce any further restrictions added by the convention. A logical place for the processing instruction might be at the top of the document after the XML Declaration, <?xml ?> , (which looks like a processing instruction but is not), though if an application needs a context-sensitive instruction, that can be added elsewhere in the document (besides within attributes, etc.).

Conventions listed here might wish to also indicate the specific processing instruction to use with their convention (e.g., <?physics-typology ?>). I'd like to propose <?tei-ext ... ?> for all such conventions, whereby pseudo-attributes within the processing instruction could indicate the name (@name) of the specific classification type or version (@version), point to a schema (@schema), or point to a namespace (@ns), etc. With the presence of this proposed (nonofficial) pseudo-convention, processors might attempt to detect whether a particular extension or its version were supported. Note that this use of the word "extension" does not imply that the document is not algorithmically conformant, as it could define a mere (conformant) subset of TEI (which could be used, for example, by an incomplete implementation of a TEI processor to determine whether it could support the document).

Namespaced attribute values

While the following idea (taken with permission from Conal Touhy) does introduce use of a non-TEI namespace, it would still seem to maintain TEI conformance (not simply TEI conformable) since it does not introduce content foreign to TEI (it just prefixes them and could be used by stricter processors to say check that each "namespace" was declared) and the mere adding of a namespace (but not introducing any elements or attributes in that namespace which would require introduction in the schema) is a standard XML convention. (One way around needing to modify a DTD in allowing for these attribute-value 'namespaces' might be to use a pseudo-attribute (say @ns) on the proposed processing instruction, though this would not allow per-element namespaces.)

The idea is to add a 'namespace' to attribute value content, especially those such as @type which lend themselves to multiple uses, and thus the potential need to distinguish one set of types from another.

The following example demonstrates one usage (though the foreign xmlns could also be made to follow a URI rather than a generic URN):

 
<event 
	xmlns="http://www.tei-c.org/ns/1.0" 
	xmlns:pol="tag:nzetc.org,2008/politics" 
	type="pol:demonstration"/>

The prefix used in the value of @type ought to be arbitrary (in order for it to function as a genuine flexible 'namespace', albeit one not enforced by regular XML processors) - what matters is the namespace URI which is bound to that prefix, not the prefix itself. A source document might use an entirely different prefix (e.g. "political" or "p" or whatever).

An XSLT template might be used to match a @type (such as the one above) whose value is "foo:demonstration", where "foo" is whatever prefix is bound to the namespace URI "tag:nzetc.org,2008/politics" (and in a manner which does not depend on a fixed prefix):

<xsl:template match="@type
   [substring-after(., ':')='demonstration']
   [
      ../namespace::node()
         [
            name(.)=substring-before(../@type,':') and 
            string(.)='tag:nzetc.org,2008/politics'
         ]
   ]
">
   A political demonstration (not a vacuum-cleaner demonstration)
</xsl:template>

Conventions

• (List specific conventions here)

See also

• Stylesheets (for third party conventions for formatting)
• Customization (for schema customizations)