#5 measure should be typed?

Lou Burnard
John A. Walsh

I would would like to suggest that the measure element be added
to the typed class so that it has both type and subtype attributes.

The additional subtype attirbute will be useful in dealing with
currency and probably other measurements as well.

For example:

<p>This book costs <measure type="currency" subtype="USD"
reg="$8.00">eight dollars</measure>.</p>

In the above example, the currency symbol "$" in the reg attribute
is not a precise indicator of the type of currency, since it is used
for both Candian and US dollars.

I think this is a general enough case that it might merit a change in



  • Lou Burnard
    Lou Burnard

    Logged In: YES

    I dont have strong feelings about adding this element to the
    typed class, but I do think that the example quoted is
    misleading. The subtype should relate to the element, not one
    of its attributes. USD is not a subtype of measure, it's
    (possibly) a subtype of currency. Also, the reg attribute in
    the above example is being expected to do two different
    things: regularize the currency name and regularize the
    measurement itself. So (unless we want to use different
    attributes for this purpose which seems like overkill) it ought
    to be 'reg="USD 8.00"' (or CAD or HKD or...)

    Syd comments that the Guidelines should suggest exactly
    how currencies be encoded without relying on
    subtype, which seems entirely right. He also suggests
    something like <measure type="currency" reg="37.54
    which I think is also a misuse of "reg" -- it doesn't
    mean "equivalent at today's trading rate".

  • Lou Burnard
    Lou Burnard

    • labels: --> 627821
  • Logged In: NO

    Lou--thanks for your comments. I can see where the example was
    misleading, and I think it would be less misleading this way:

    <p>This book costs <measure type="currency" subtype="USD"
    reg="8.00">eight dollars</measure>.</p>

    I included the currency symbol ($) in the reg attribute because it's included
    in the examples in P4, but it is superfluous with the subtype attribute. The
    subtype attribute, in either case, is intended to refer to the element, not
    an attribute. Currency is a type of measure, and USD is a type of
    currency, regardless of wether the local currency symbol is included in the
    reg attribute.

    So I still lobby for for measure in the typed class.

  • Lou Burnard
    Lou Burnard

    • labels: 627821 --> TEI: New or Changed Element
  • Syd Bauman
    Syd Bauman

    Logged In: YES

    The following is more a thought experiment out loud than
    anything else. Take it with a grain of salt ... or two.

    Since "in its fullest form, a measure consists of a number,
    a phrase expressing units of measure, and a phrase
    expressing the commodity being measured", I'm inclined to
    say that type= of <measure> should be dropped in favor of
    three attributes, let's call them num=, unit=, and stuff=.
    This permits regularization of each component of the measure
    separately, and thus also would permit us a more precise
    semantics of reg= (either the normalization of num= or the
    normalization of both num= and unit= together; might even
    want to call it norm=, removing <measure> from the name
    class, thus removing the key= attribute, which I daresay
    seems a bit silly, although perhaps I'm overlooking
    something here).
    However, this doesn't actually address the problem John was
    pointing out, which is that sometimes it's useful to
    indicate what dimension (wrong word, but I can't think of a
    better one right now) a particular unit is measuring. So
    just as "CAD", "SEK", and "EUR" are all units of "currency",
    it is also the case that "metre", "mile", and "light-year"
    are all units of "distance". It is reasonable to expect that
    at times people may wish to indicate this larger category
    instead of or in addition to the actual unit.
    But before we go attribute-crazy, we need to also think
    about which of these bits of information need to be elements
    rather than attributes (such that information about them,
    e.g. their language, can be supplied).

  • Logged In: YES

    There are 80 or 90 elements in the TEI which have
    a "type" attribute already, not inherited from the class
    l"typed". Rather than look at just <measure>,
    I'd rather that we took all these elements, and those
    that are now in "typed", and either
    a) decide they should all be "typed" and so get a subtype
    b) be allocated into either a simple "typed" class, which
    just adds "type", or into a new "complextyped" class, which
    adds type, subtype and conceivably other attributes in future.

    My immediate assumption would be that anything which
    can have a type can also have a subtype.

  • Syd Bauman
    Syd Bauman

    Logged In: YES

    Many, if not most, of the elements that declare their own
    type= attribute do so for a reason. Either because it's
    required, has a TEI-defined controlled vocabulary, or has a
    "suggested values include" list, or some such. While I think
    it's a good idea to look at this set of elements with some
    scrutiny, and also to work on the entire TEI class system, I
    don't think either should preclude our deciding whether or
    not it's a good idea that <measure> have a subtype= attribute.

    While in some sense anything that can have a type can have a
    subtype, the same logic says that anything that can have a
    subtype can have a subsubtype. I'd prefer not to go there,
    and am strongly against the idea of globally just adding
    subtype= to anything that has type=.

    -- In haste

  • Syd Bauman
    Syd Bauman

    • assigned_to: nobody --> sbauman
  • Logged In: YES

    well, of course all free-standing type attributes are there
    for a reason. similarly, all members of tei.typed are there
    for a reason. but the distinction between the two ways of
    getting a type attribute does not seem to be clear. If its
    because the local "types" are mandatory,
    then lets say so. if its because there are a list of
    suggested values, then we need to be able to express that in
    ODD, so its an ODD bug.

    we can't answer "should <measure> have a subtype attribute
    attribute" without explaining what tei.typed is for and what
    the common feature of its 5 or 6 members is.

  • Perry Willett
    Perry Willett

    Logged In: YES

    I think I need to hear more about how John wants to encode
    this, beyond this one example. I'm having a hard time figuring
    out why someone would want to do this type of encoding. Is
    this the real example, or is this example invented for a point?
    If the former, what's the larger encoding context--why do you
    want to do this? If the latter, what is the real example?


  • Logged In: YES

    I rather agree with Sebastian's comment below. I remember
    at some point somebody made the comment that all
    elements should have a type attribute. I think I'd agree with
    this, particularly as the TEI is being used for more and more
    types of encoding.

    I was encoding documentation at the weekend for
    teiPublisher and found I wanted a type attribute on <figure>
    as are using the documentation for both a printable document
    converted into HTML, and within the application itself. For the
    printable version, I wanted the screen shots to be displayed,
    but did not want them when we use it in the application.

    For many instances, I could nest the <figure> in a <div>, but
    at times I wanted the figure to be within a list item. Here, a
    type attribute would have done the trick.

    I have no problem with John's request, moreover, I'd like to
    see the option of using type more broadly generally.

  • BODARD Gabriel
    BODARD Gabriel

    Logged In: YES

    Without getting involved in the discussion of whether to use
    @type/subtype or @type/@unit for the moment, a further
    example of what we need to mark up with <measure>.

    It would seem useful to be able to specify, for example,
    that in our project <measure type='length'
    dim='height'>0.74</measure> is in metres, and is therefore
    equivalent to another project's database field 'Hhe: 74'
    (in centimetres). For purposes of calculation and
    transformation, the use of a unit in @reg would not seem to
    be sufficient.

  • Lou Burnard
    Lou Burnard

    • assigned_to: sbauman --> louburnard
    • status: open --> closed
  • Lou Burnard
    Lou Burnard

    Logged In: YES

    Discussion of this seems to have diverged beyond what can
    conveniently be resolved here. Release 0.3 now has a new
    <measure> element which I think addresses some of the
    original requirement. The discussion about the function
    and hence the proper use of the typed class vis-a-vis a
    specific type attribute is ongoing and unresolved: it
    needs to be addressed within the scope of the class war
    though, not here. So I'm closing this ticket, unless
    anyone cares to reopen it.