Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo


#491 Descriptions of data.enumerated values

John P. McCaskey

These descriptions are more (in some cases much more) flexible than their datatype (data.enumerated) in fact allows. Some aren't literally inconsistent, just potentially misleading. Some, however, are in conflict.

<titlePage>/@type: "Any string, e.g. full, half, Series, etc."

<app>/@type: "Any convenient descriptive word or phrase, describing the extent of the variation (e.g. word, phrase, punctuation, etc.) its text-critical significance (e.g. significant, accidental, unclear), or the nature of the variation or the principles required to understand it (e.g. lectio difficilior, usus auctoris, etc.)"

<distinct>/@type: "a semi-open user-defined list"

<forest>/@type: "A character string."

<fs>/@type: "Character string, e.g. word structure."

<lbl>/@type: "any string of characters, such as usage, sense_restriction, etc."

<listForest>/@type: "A character string."

<orth>/@type: "Any convenient word or phrase, e.g. lat (latin), std (standard), trans (transliterated), etc."

<witDetail>/@type: "Values can be taken from any convenient typology of annotation suitable to the work in hand; e.g. letter_form, ornament, …"


  • Lou Burnard
    Lou Burnard

    These <valDesc> elements are retained from a pre-datatype version of the Guidelines and are often inconsistent or misleading in this way; they were retained in case they provided useful constraints that might be re-expressed using schematron. I have now removed the ones you list above, and there is an ongoing activity to check the remainder.

  • Lou Burnard
    Lou Burnard

    • status: open --> closed-accepted