Every validated TAN file will include the following message at its root.This version of TAN is under development, and is subject to change. Participants in developing the TAN schemas, functions, and guidelines are welcome. See http://textalign.net for details.
Every TAN file must have a primary agent, the organization or person that takes the greatest responsibility for the content of the TAN file. The primary agent is defined as the first <agent> with an <IRI> that is a tag URI whose namespace matches the namespaces of @id in the root element.
Any TAN file marked as being no longer in progress should have at least one master-location.
@xml:id values may not be repeated in the same document.
@href must have <location> or <master-location> as a parent; any other parent will trigger a quick fix to populate the element with the IRI + name pattern of the target file.
If fn:doc-available() for an @href returns false, the following message will be returned.@href points to file that is either (1) not available, (2) not valid XML, or (3) at a server not trusted by the validation engine.
The only @href in a TAN document that may point to the same document id that of <master-location>
An IRI may appear no more than once in a TAN document.
An IRI that names a TAN file must match that file's @id exactly.
No file may import keys that have duplicate IRIs.
All text must be normalized (Unicode NFC).
Every idref in an attribute must point to the @xml:id value of the appropriate corresponding element.
All idrefs in an attribute must be unique.
Attributes that take a regular expression must use escape sequences recognized by XML schema or TAN escape extensions (\k{}). See http://www.w3.org/TR/xmlschema-2/#regexs for details.
No single set of references may mix Roman numerals, alphabetic numerals, and numerals that are ambiguously either.
A <alias> may not mix idrefs from different elements.
<alias> references must not be circular.
No <master-location> may have an @href that points to a compressed archive.
Any <see-also> whose <relationship> is defined as requiring a target TAN file must point to a file whose root element is a TAN file.
Any <see-also> whose <relationship> is defined as requiring a target TAN-c file must point to a TAN file whose root element is <TAN-c>.
Any <see-also> whose <relationship> is defined as requiring a target copy must point to a TAN file whose root element is identical.
<see-also> may have the <relationship> of a different work version only if both are class 1 files and both share the same work.
In class 1 files, alternative editions must share the same source.
In class 1 files, alternative editions must share the same work.
In class 1 files, alternative editions must share the same work-version, if supplied.
In class 1 files, resegmented copies must have identical transcriptions, after TAN normalization.
A class 1 file and its model must have the same work.
A class 1 file may have no more than one model.
If a class 1 file diverges from the structure of its model a warning will be generated specifying where differences exist.
Inclusions may not introduce duplicate values of @xml:id.
For any element with @include, at least one element of the same name must be found in target inclusion document.
Inclusions may not be circular.
Inclusions are integral parts of any TAN file. Access to at least one copy is absolutely mandatory.
Every inclusion should have at least one document available.
Every element with a <location> should have at least one document available.
Every TAN file referred to by way of an element containing <location> should have an @id that matches the <IRI> of the parent of the <location>
No element may point to a TAN file that has an identical @id value; the only exception is a <see-also> pointing to an older or new version.
If @when-accessed predates one or more dates in a target file, a warning will be returned.
If a target file does not explicitly give the <body>'s @in-progress the value of true() a warning will be returned.Target file is marked as being in progress.
If a target file has a <see-also> marked as a new version (update) a warning will be returned.
Date attributes must be castable either as xs:dateTime or xs:date
Future dates are not permitted.
@from must predate @to
An element's @which must have a value that corresponds to a <name>, either in the core TAN keyword or an associated TAN-key file, that is marked as applying to that element.
Keywords (values of @which) must be unique for a given element name.
Any element that takes @which must have keywords defined for that element.
Keys are integral parts of a document. Access to at least one version is absolutely mandatory.
Every atomic reference in a @ref must correspond to a <div> in every source mentioned by @src.
Every range in a @ref must correspond to one or more <div>s in every source mentioned by @src.
If @ref points to a leaf div, it must be unique.
A defective reference is a value of @ref that corresponds to a <div> in some but not all sources in a work. If a defective reference is used, a warning will be reported, identifying the sources that lack the appropriate <div>.
Every token must be locatable in every cited ref in every source.
<tok> must reference a leaf <div>.
A <div> may be referred to in a <realign> no more than once (whether <anchor-div-ref> or <div-ref>).
Items that share IRI values should not be equated.
@seg may not be applied to any element that is not a leaf div
Distribution must be applied to groups of equal size.
Splits may be made only at leaf divs.
No <div> that is a member of a complex realignment may be used to align all members of a work (@src should be used instead of @work)
Sequences may not include values less than 1.
Sequences may not include values greater than the maximum allowed.
Sequences may not include ranges that go from a larger value to a smaller, e.g., 4 - 2.
A work element may invoke no more than one inclusion.
Leaf div references must be unique.
@n's taking digit values should not begin with 0.
Every leaf div must have at least some non-space text.
No div may begin with a modifying character.
No div may have a spacing character followed by a modifying character.
No div may have Unicode characters that are disallowed, e.g., U+A0, NO BREAK SPACE.
<div>s may not be mixed with other elements: a <div> must parent either only <div>s or none at all, and may have as siblings only other <div>s.
A <div> must not mix @include with any other attributes.
A <div> must have either @type + @n or @include but not both.
@n suffices for labeling text in a <div>; the @n's value should not appear in the text.
concatenated @n's suffice for labeling text in a <div>; the <div>'s reference should not appear in the text.
@rend should be used to represent a break, not actual text
A breaking element without @break="no" should have at least one space on either side; one with @break="no" should have no nearby spaces
To avoid ambiguous numerals, no div type should mix Roman and alphabet numerals.
Sources are integral parts of a class 2 TAN file. Access to at least one copy is absolutely mandatory.
No source may be given more than one token definition.
Every div type reference must be valid in every source
@old and @new may not share the same value
No value of @new or @old may appear more than once for a given div type in a given source.
@old must be found in every div type of every source
Any element taking @cont must be followed by at least one sibling of the same type.
@val must wholly match a token in the target.
A @val set to '.+', a regular expression that matches any string, is equivalent to the omission of @valThe value '.+' will match any string.
No source may be split more than once in the same place.
Splits may not be made at the first token in a div.
A <tok> may not duplicate any sibling <tok>.
Any ana with an @xml:id must point to no more than one token.
When using a category-based morphology, the number of feature codes in an <m> may not exceed the number of categories.
Every feature code in an <m> must be found in the target morphology file.
Every condition of a relevant <assert> (<report>) must be true (false) otherwise an error will be returned.
Every condition of an uncertain but relevant <assert> (<report>) must be true (false) otherwise a warning will be returned.
Names may not duplicate reserved TAN keywords for the affected element.
Names may not be duplicates of, case-variants of, or hyphen variants of other names for the same element.
@affects-element must include only names of TAN elements that accept @which
Every item in a reserved TAN-key must have at least one IRI with a tag URN in the TAN namespace
Every <feature> inclusion must support every language that has been declared.
Codes for (@xml:id or @code) features must be case-indifferently unique within a given category.
@feature-test and @context must point to one or more feature @codes or @xml:ids a space or +
Claims involving verbs whose object is constrained must use <object>, not @object.
Verbs that have object constraints must not be combined with other verbs in @verb.
<object>s taking strings must match the predefined @object-datatype for the verb.
<object>s taking strings for verbs that have lexical constraints must match those lexical constraints.
Every <claim> must have at least one subject, either @subject (self or ancestral <body>) or a child <subject>
Any predefined strictures on verbs must be respected.
Every <claim> must have at least one subject, either @subject (self or ancestral <body>) or a child <subject>
Token-based assertions of multiple class 2 TAN documents that share the same class 1 source may be compared or collated only if those class 2 documents adopt identical token definitions.
Assertions of multiple TAN-A-div documents that share the same class 1 source may be compared or collated only if they suppress, or fail to suppress, the same div types.
Mismatched sets of statistics may not be merged.