#175 new attribute @rational on num

AMBER
closed
6
2009-06-02
2009-03-08
BODARD Gabriel
No

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)

Discussion

  • Lou Burnard
    Lou Burnard
    2009-03-14

    • milestone: --> AMBER
     
  • Lou Burnard
    Lou Burnard
    2009-03-14

    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?)

     
  • Peter Boot
    Peter Boot
    2009-03-16

    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.

     
  • David Sewell
    David Sewell
    2009-03-17

    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

     
  • BODARD Gabriel
    BODARD Gabriel
    2009-03-17

    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?

     
  • BODARD Gabriel
    BODARD Gabriel
    2009-03-17

    • assigned_to: nobody --> rahtz
     
  • David Sewell
    David Sewell
    2009-03-17

    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.

     
  • Lou Burnard
    Lou Burnard
    2009-03-22

    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

     
  • Lou Burnard
    Lou Burnard
    2009-06-02

    • status: open --> closed
     
  • Lou Burnard
    Lou Burnard
    2009-06-02

    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.