cl101 wrn02 wrn03 wrn04 rea03 ref02 cl102 cl207 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 TAN files whose last change was made by an algorithm. Files must be correlated with the proper TAN version. Every TAN file must have at least one organization or person with an <IRI> that is a tag URI whose namespace matches the namespaces of @id in the root element. Any TAN file without a to-do list will be treated as being no longer in progress and should have at least one master-location. @xml:id values may not be repeated in the same document. An @xml:id on a vocabulary item need not duplicate a <name> (except in a TAN-mor file). @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 an @href points to a local file that is not available, a warning will be returned.@href points to file that is either (1) not available or (2) not valid XML If an @href points to a file that is not local, and no internet is available, a warning will be returned.No internet access. If the internet is available, and an @href points to a non-local file that is not available, a warning will be returned.@href points to non-local 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 another document with the same document id is that of <master-location> or <see-also> 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 vocabularies with items that have duplicate IRIs. All text must be normalized (Unicode NFC). Every idref in an attribute must point to a vocabulary item (by @xml:id or name) that is of the appropriate corresponding element. All idrefs in an attribute must be unique. Multiple idrefs in a single attribute should not point to the same entity. Attributes that take regular expressions must use escape sequences recognized by XML schema or TAN escape extensions (\u{}). See http://www.w3.org/TR/xmlschema-2/#regexs <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>. An inclusion must point to a TAN file <successor>, <predecessor>, and <companion-version> must point to TAN files of the same type. <model> and <redivision> must point to class 1 TAN files <annotation> must point to class 2 TAN files <vocabulary> must point to TAN-voc files. <morphology> must point to TAN-mor files. For any element with @include, at least one element of the same name must be found in target inclusion document. Inclusions are integral parts of any TAN file. Access to at least one copy is absolutely mandatory. Inclusions/vocabularies may not be invoked circularly. The vocabulary of a file may not include it. The @TAN-version for inclusions and vocabularies should match the current version. An element that has a <location> and is key for validation 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 <predecessor> and <successor>. If a target file has children items in the <to-do>the corresponding comments will be returned as warnings. If a target file has a <successor> a warning will be returned, noting the update. If an element's <location> is faulty and if a catalog file entry is found pointing to a document with the same IRI, location information on those alternative locations will be returned If a target file points only to non-local locations and no internet is available, the following message will be returned.No internet available. If a linking element points to a file that must be resolved, that file must be a TAN file. If an element not essential to validation has no <location> that points to a document a warning should be returned. If @accessed-when predates one or more dates in a target file, a warning will be returned. Future dates are not permitted. @from must predate @to An element's @which must have a value that corresponds to a <name>, either in a standard TAN vocabulary or an associated TAN-voc file, that is marked as applying to that element. A @which in a <vocabulary> may point only to items in the standard TAN file vocabularies.TAN-voc.xml Vocabularies are integral parts of a document. Access to at least one version is absolutely mandatory. Names must be unique for vocabulary items assigned to a given element name. 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 redivision or companion version. Class 1 files must share the same work-version, if supplied, as any redivision. Class 1 files must have identical transcriptions, after TAN normalization, as any redivision. If a class 1 file diverges from the structure of its model a warning will be generated specifying where differences exist. Class 1 files must share the same work as any model, redivision, or companion version. Most div references are 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. No reference may point to a mixture of leaf and non-leaf <div>s. An @n's value should not appear in the text. A <div>'s reference (self and ancestor @ns, concatenated) 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 milestone element without @break set to false should have at least one space on either side. A milestone element with @break set to false should have no nearby spaces A class 1 <source> may not point to a TAN file. 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 for that work, a warning will be returned. In a @ref range the first reference should precede the second. Every token must be locatable in every cited ref in every source. Every character must be locatable in every token in every ref in every source. Any range in either an @n or in a @ref in an adjustment action must be predictably calculated. Only the first of multiple adjustment actions will be applied. Action priority: skip, ref-based rename, then for every @n n-based rename, equate. In adjustment actions involving @n, at least one 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 quantity of values in @ref and @new must be identical. Sources are integral parts of a class 2 TAN file. Access to at least one non-faulty copy is absolutely mandatory. No source may be given more than one token definition. Every div type reference must be valid in every source The values of @n in <equate> should not have duplicates. @new may not take the same value as what it replaces. At least one @n value in an equate should be found in every source. No token may be adjusted by more than one <reassign>. A <reassign> may be applied only to leaf <div>s. 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 adjustment action should result in the mixing of leaf <div>s and non-leaf <div>s. In a <reassign>, the token referred to at <from-tok> must precede the one referred to by <through-tok>. Claims involving verbs whose constrained content requires specification of units must use <object> or <subject> with @units. <object> or <subject> with @units may be used only with verbs with constrained content. A claim with a verb that has content constraints must not allow other verbs. <subject>s' and <object>s' content must be castable to any datatype constraints defined by the verb. <subject>s' and <object>s' content must match any lexical constraints defined by the verb. Every <claim> must have or inherit at least one verb. Every <claim> must respect constraints defined by the verb. No <claim> with a verb that disallows an element may have another verb that requires that same element. 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 names reserved by standard TAN vocabulary for the affected element. Names may not be duplicates of, case-variants of, or hyphen variants of other names for the same element. Each <name> in standard TAN vocabulary must already be normalized. @affects-element may take names only of those TAN elements that accept @which @affects-element may take the value "vocabulary" only in official TAN-voc files. Every item in a reserved TAN-voc must have at least one IRI with a tag URN in the TAN namespace Features may not be repeated within a given category. Codes 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 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.