#328 <valDesc> contents need to be checked

GREEN
closed-accepted
Martin Holmes
5
2012-03-26
2011-12-09
Martin Holmes
No

This is Lou's summary of the problem first raised in the specific case of @n in <http://purl.org/TEI/BUGS/3441933> (now fixed):

I think that a systematic sweep of
<valDesc>s will show very many such discrepancies. Basically <valdesc>
dates from a time before <datatype>s were formalised in the ODDs, and
thus contain all sorts of descriptive garbage, much of which is now
wrong. We have however retained them, because in some cases they
describe useful intended constraints which we would hopefully now
represent using <constraint>s.

So, in a nut shell

a) if there is a conflict between datatype and valdesc, the former is
right and the latter should be nuked ... except that

b) all valdescs need to be examined carefully to see whether they can be
re-expressed in schematron first

Discussion

1 2 > >> (Page 1 of 2)
  • Martin Holmes
    Martin Holmes
    2012-01-10

    I've created an HTML table of all the TEI attributes and their datatypes and descriptions here:

    http://web.uvic.ca/lancenrd/martin/tei/valdescs.htm

    I'm going to go through these and list those which I think require action.

     
  • Martin Holmes
    Martin Holmes
    2012-01-27

    Found and fixed one (rev 10060):

    @given on <certainty>: list of pointers, but valDesc has "a pointer".

     
  • Martin Holmes
    Martin Holmes
    2012-01-27

    Re-thinking this, I believe that a) is more important than b), and should be carried out as soon as possible, since conflicts are misleading for users, and constitute errors in the guidelines. b) can be carried out at any point, and applies to all valDescs, not only those which are out of sync with their datatypes. So I'm ignoring b) for the moment, and focusing on a).

     
  • Martin Holmes
    Martin Holmes
    2012-01-27

    A problematic instance is @cRef (<gloss>, <term>, <pointer>, <ref>). There are various issues associated with @cRef, so I've created a separate ticket for it:

    http://purl.org/TEI/BUGS/3480650

     
  • Martin Holmes
    Martin Holmes
    2012-02-08

    Another change committed: <tag>/@scheme brought into line with <att>/@scheme and <gi>/@scheme by making its valList open rather than closed, and by making its suggested values the same as those for <gi>. This following an exchange on the Council list arising out of this bug.

     
  • Lou Burnard
    Lou Burnard
    2012-03-13

    • milestone: --> GREEN
     
  • Lou Burnard
    Lou Burnard
    2012-03-13

    I'm putting this in the green group since it's clear what needs doing, and martin is clearly doing it!

     
  • Martin Holmes
    Martin Holmes
    2012-03-13

    I think I've basically finished a), and am going to move on to b), but I'm not sure about the Schematron bit -- I haven't used Schematron lately, and I'm not sure how it fits into the build system. Should I be writing new tests for the P5Tests target which check the values of attributes?

     
  • Lou Burnard
    Lou Burnard
    2012-03-26

    I suggest that you close this ticket, which concerns (a), and that you produce a separate document for Council to consider which lists proposed schematron rules for (b). This might also include a sample document testing that those rules are firing correctly. Happy to help with the latter task if nessa.

     
  • Martin Holmes
    Martin Holmes
    2012-03-26

    Ticket closed, and the schematron issue spun off into a separate ticket:

    http://purl.org/TEI/BUGS/3511398

     
1 2 > >> (Page 1 of 2)