- milestone: --> AMBER
We need an attribute such as @rational (or @alt or @fraction aut sim.) for when the normalized numeric value of the number being encoded is better represented in some form other than a pure decimal number as imposed by data.numeric. This might include non-simple fractions (1/3 or 5/12), where the ratio itself is of more interest than the decimal value rounded to some number of significant figures.
e.g.
<num value="0.042">κδ</num> (where _kd_ is the ancient Greek for 24 or in this case 1/24)
<num rational="1/24">... (would give more useful information for both searching and for analysis of numeric patterns in manuscript)
Are there numeric values which cannot be represented either as decimals or as fractions? how long will it be before TEI encoders start wanting exponent notations, complex numbers etc...
absolutely there are. :)
Well, I haven't heard anyone asking for them yet. But if they have a compelling case for them then I guess we'll need to cater (or recommend mathML or something).
(Actually, you can do decimal exponents in data.numeric, can't you?)
I see there is a need to so something about this.
Another solution might be to add a new attribute valuetype which defines how to interpret the value attribute. This would help us prepare ourselves for other cases in the future.
We could then have <num value="1/24" valuetype="fraction">.
This would require the datatype of an attribute to depend on another attribute's value. Not sure whether this can be done in NG. In Schematron it should be possible.
Allowing num/@rational as a complement to num/@value is a simple
solution to the problem that would meet many people's needs, but I don't
see it as an elegant general-case solution to the problem of associating
the textual content of <num> with an unambiguous and/or processable
value. Just to take one of the most obvious examples,
<p>Is it true that some fundamentalists wanted to define
<num>pi</num> as equal to <num>3</num>?</p>
You can't express pi with either @value or @rational. It would probably
be better for us to defer to a more systematic language like MathML if
people need to express complex numeric values, probably by means of a
referring attribute. Maybe add <num> to att.declaring so one could point
to a chunk of MathML in the header...
Anyway, I wouldn't object to adding @rational as proposed by Gaby. I
don't think the @value/@valuetype solution will work as complex values
will be hard to express as character data.
David
I do like the idea of @value + @valueType; that's much more elegant than my proposal. Can Sebastian comment on the question of whether this is really unimplementable in RNG?
I'm going to revise my earlier opinion to support adding @valueType to <num>. It would in fact allow a great many numeric values to be captured in a simple way. For example:
<p>The computer gave a cryptic response: <q><num type="binary" value="42" valueType="decimal">101010</num>!</q>, it shouted.</p>
<p>He owned <num value="2/3" valueType="fraction">2/3</num> of the property.</p>
<p>Has Google actually indexed <num value="1E100" valueType="float"> one googol</num> Web pages yet?</p>
(In the first example, @type applies to the element content, @valueType to the content of @value. We would need to make this distinction clear in the documentation.)
The easiest thing for us to do would be to (1) add @valueType as an optional attribute (and make explicit that if there is no @valueType, then any @value is interpreted as decimal), and (2) provide a suggested list of @valueType values (decimal, fraction, float, hex, octal, binary ... ?) and examples of usage.
*Constraining* usages would be much trickier, and I don't believe it is possible in RELAX NG as the legal patterns for @val would depend on the declared @valueType. But one could write Schematron rules to enforce the syntax of known patterns.
This feature request seems to have changed its shape slightly: if the idea is indeed not to add @rational, but rather to add @valType to complement @value, I think that we need agreement on the possible values for @valType. Is it a closed or an open list? In my view, it should be a closed list. Also, I think the purpose of this is *not* to allow identical @values to be given using different representations, but to allow for @values which can *only* be expressed in some different format (e.g. irrational numbers or fractions). So I would not allow hex, octal or binary, since these are all different ways of representing the same intended values. (If you doubt this, consider the case of a hex string which represents a floating point number in the usual mantissa+exponent form: what use is it to be told this is in hex if you don't know it's actually representing a float? the same hex string could equally well be representing an integer value in 2s complement format! So it's not helpful to be told it's in hex -- much more use to be told it's a float!
I suggest the values should be just the following:
decimal (default)
float (the @value contains a mantissa and an exponent e.g. 2.356e1000)
ratio (the @value contains two integers and a slash e.g. 22/7)
I cannot for the life of me see the point of using @type on <num> to show how its *content* is represented. The usage for this attribute proposed in the Guidelines is more to do with the *value* with suggested values ordinal, fraction, percentage.
use schematron to enforce co-dependency between attributes
Following further discussion on TEI-Council list, I've now changed data.numeric to permit fractions. This seems the easiest way of satisfying the specific use case mentioned (the ability to provide a normalised value for irrational numbers) without the overhead of trying to enforce consistency between attribute values. The testlite test file has been modified to include a check.