[tei-council] num

[Lou Burnard]

Please forgive me for bringing this up again, but I am not convinced 
that the decision we appear to have agreed in Lyon re.# 2673045 is the 
best one and I am uncertain how to proceed.

If you look at the ticket 
(https://sourceforge.net/tracker/?func=detail&aid=2673045&group_id=106328&atid=644065)
you'll see that what Gabriel wants is the ability to represent the value 
of the @value attribute on num as a fraction e.g. 34/56

In Lyon we agreed that the way to do this was to define another 
attribute @valueType with possible values decimal, float, and ratio. I 
can do that easily enough, but it won't help Gabriel's original 
requirement unless I also change the  datatype of the @value attribute 
to permit values such as "34/56" (presumably by defining some sort of 
pattern). At present @value is data.numeric which is mapped to a choice 
of XSD schema types "double" and "decimal", neither of which would 
support fractions.

In Lyon we did not discuss this aspect of the problem (or if we did I've 
forgotten  it) and I can't see any discussion of it in the ticket 
either.  Was the intention to  (a) just forget about validating the 
@value attribute or to (b) extend its possibilities to include a pattern ?

Thinking about this problem on the train home , I felt that this was 
really not the right way of approaching the issue. I think what Gabriel 
asked for in the first place -- a different  value-bearing attribute -- 
was the right answer.  Having an attribute that tells you  whether 
another attribute is
decimal, float, or ratio  seems redundant in a world where  you already 
have datatype checking.
Extending the range of an existing constrained datatype to include 
something which  many processors will regard as just plain broken seems 
a really dangerous idea. And I don't even want to think about the 
problems of how you determine  what combinations of values for these two 
attributes are mutually consistent.

My recommendation is that we don't introduce a @valueType attribute. 
Instead  we introduce a  @ratio attribute (better names welcomed), the 
value of which is constrained by a pattern something like \d+\/\d+ and 
which is not allowed to coexist with the @value attribute (that is 
something I think we can already represwent in ODD, tho I suppose a 
schematron rule would also be a good idea)

Apologies again for digging this up again, and for the delay in 
implementing decisions we thought we'd agreed to!