#491 Descriptions of data.enumerated values

closed-accepted
nobody
5
2013-01-09
2013-01-01
No

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, …"

Discussion

  • Lou Burnard

    Lou Burnard - 2013-01-09

    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 - 2013-01-09
    • status: open --> closed-accepted
     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks