Yes, the real difference is that for teidata.enumerated then you should have a valList in your ODD enumerating the specific values for your project. Indeed... if we wanted to add checks into an ODD editor like Roma, one could have it check through all classes and elements included in the ODD and find any attributes with teidata.enumerated and check that they have a valList, and if not prompt a user to enter one. That would, however, be quite strict, so maybe only in a future checker 'strict' mode (otherwise just a warning). ;-)

Many thanks,

James

Dr James Cummings, James.Cummings@newcastle.ac.uk
Senior Lecturer in Late-Medieval Literature and Digital Humanities

School of English, Newcastle University

Sounds fine to me. It looks like teidata.enumerated is just a wrapper for teidata.word anyway...?

Raff

On Mon, Aug 19, 2019 at 2:20 PM James Cummings <James.Cummings@newcastle.ac.uk> wrote:

https://github.com/TEIC/TEI/issues/1908

https://jenkins.tei-c.org/job/TEIP5-dev/lastSuccessfulBuild/artifact/P5/release/doc/tei-p5-doc/en/html/ref-org.html

Although I fixed the corrigible error for this ticket 25 days ago (within minutes of it being submitted ;-)) I noticed that the datatype for the @role attribute on <org> is teidata.word. For another issue I was looking at the @role attribute usage in other places and it is usually teidata.enumerated and that would make sense with this attribute as well.

Any objections if I modified tei:org/@role to be teidata.enumerated instead of teidata.word? (This has no backwards compatibility issues as far as I'm aware, but means that a project _should_ document this list of possible values... which is a good thing.)

Many thanks,

James

--

Dr James Cummings, James.Cummings@newcastle.ac.uk
Senior Lecturer in Late-Medieval Literature and Digital Humanities

School of English, Newcastle University

_______________________________________________
Tei-council mailing list
Tei-council@lists.tei-c.org
http://lists.lists.tei-c.org/mailman/listinfo/tei-council