wrn02

wrn03

wrn04

rea03

ref02

Users should be warned about versions of TAN that are under development.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. Users should be warned about versions of TAN that are semi-stable.This version of TAN is semi-stable. RELAX-NG schemas will be changed only to correct egregious errors. Other files might be edited, but most efforts on improvement will be spent on future versions. Files that point to older versions of TAN rules will be pointed to conversion stylesheets. 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 is that of <master-location> No @href should point to the URI of the document itself. 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. Any IRI beginning urn: must continue with a name that is part of the official IANA Registry of URN Namespaces. See RFC 2414, https://tools.ietf.org/html/rfc8141, and https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml 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 (\u{}). See http://www.w3.org/TR/xmlschema-2/#regexs An <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. Files should match the version kept at <master-location>. 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 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. 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 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 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. If @when-accessed predates one or more dates in a target file, 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. Sequences may not include values less than 1. Sequences may not include values greater than the maximum allowed. Ranges in sequences must go from a lesser value to a greater. Class 1 files must share the same source as any alternatively divided edition. Class 1 files must share the same work as any model or alternatively divided edition. Class 1 files must share the same work-version, if supplied, as any alternatively divided edition. Class 1 files must have identical transcriptions, after TAN normalization, as any alternatively divided edition. 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. A work element may invoke no more than one inclusion. Leaf div references must be unique. An @n taking digit values should not begin with 0. Every leaf div must have at least some non-space text. No text may begin with a modifying character. No text may have a spacing character followed by a modifying character. No text 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. Text that represents a line, column, or page break should be moved into a @rend within a <lb>, <pb>, or <cb>. A breaking element without @break="no" should have at least one space on either side; one with @break="no" should have no nearby spaces Every part of a @ref must correspond to a <div> in every source. If a reference to a work is not found in some sources, a warning will be returned. Every token must be locatable in every cited ref in every source. <tok> must reference a leaf <div>. Every character must be locatable in every token in every ref in every source. Ranges consist of exactly two values separated by a hyphen. When renaming references, ranges must be predictably calculated. At least one instance of an @n value should be found in each source. @by may be applied only to those @n and @ref values that are calculable as integers. In a <rename>, the number of values in @ref and @new must be identical. If more than one <skip> applies to a <div> only the first will be applied. 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 @new may not take the same value as what it replaces. Only the first of multiple <rename>s that apply to a particular <div> will be applied. Only the first of multiple <reassign>s that apply to a particular token will be applied. If a <div> is renamed, and the target reference is subject to <reassign> instructions, the following message will appear.<reassign> targets a reference that has been altered by <rename>. Any reassignments will treat the newly created <div>, not the original. No alter action should result in the mixing of leaf <div>s and non-leaf <div>s. No <tok> should duplicate any sibling <tok>. In a ranged <tok> in a <reassign>, the token referred to by <from> must precede the one referred to by <to>. 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 verb, either @verb (self or ancestral <body>) <for-lang> and <source> are mutually exclusive in a TAN-A-lm file. A TAN-A-lm file must have either <for-lang> or <source> 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 dependency morphology <assert> (<report>) must be true (false) otherwise an error will be returned. Names may not duplicate reserved TAN keyword names 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 An item may take @object-datatype and @object-lexical-constraint only if the governing @affects-element is set to 'verb' Id values for features must be case-indifferently unique within a given category. Every @href in a catalog.tan.xml file must point to a document that is available. @href values in catalog.tan.xml should be unique @root should match the target's root element name In a catalog.tan.xml, @id should match the target's root element @id Different TAN files should have unique @ids. If a local catalog.tan.xml file lacks a reference to a TAN file being validated, a warning will appear. A TAN file being validated verbosely will include errors reported in any local catalog.tan.xml 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.