#328 <valDesc> contents need to be checked


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


  • Martin Holmes

    Martin Holmes - 2012-01-10

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


    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:


  • 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:


  • Martin Holmes

    Martin Holmes - 2012-03-26
    • status: open --> closed-accepted

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

Sign up for the SourceForge newsletter:

No, thanks