[tei-council] Spec for @n (ticket # 3441933)

[Lou Burnard]

This is fine, however... . 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

sounds like a job for the Proof Reader Extraordinaire to me.


On 09/12/11 17:10, Martin Holmes wrote:
> In<http://purl.org/TEI/BUGS/3441933>, Michelle Dalmau rightly points
> out that the formal datatype of @n differs from the value description:
>
> [quote]
> Datatype 1–∞ occurrences of data.word
>
> separated by whitespace
>
> Values 	the value may contain only letters, digits, punctuation
> characters, or symbols: it may not contain whitespace or word separating
> characters. It need not be restricted to numbers.
> [/quote]
>
> My guess is that this arose because at some point the datatype was
> changed to allow multiple values, but the<valDesc>  was not altered to
> match it. I've therefore expanded the valDesc as follows:
>
> "The value consists of one or more instances of data.word. Each instance
> may contain only letters, digits, punctuation
> characters, or symbols: it may not contain whitespace or word
> separating characters. It need not be restricted to
> numbers."
>
> This seems an important issue and I'd like to get it into Laurentian, so
> I've committed this change. If there's something I'm missing, or if it's
> the wrong solution, please correct me asap.
>
> Cheers,
> Martin
>