#470 att.measurement and att.dimensions overlap

RED
open-later
Martin Holmes
None
5(default)
2014-09-09
2013-08-25
Lou Burnard
No

<measure> and <measureGrp> are the only members of att.measurement ("provides attributes to represent a regularized or normalized measurement") which supplies attributes @unit @quantity and @commodity. Most things which are measurements are members of att.dimensions ("provides attributes for describing the size of physical objects") which supplies its own definitions for @unit and @quantity, doesn't have @commodity, but does have others (@extent, @precision, @scope)

This should be regularised. I think the original idea was that @unit in att.measured should allow only an SI unit, but all the examples show that this was unworkable. We could

  • keep att.measured as is (or modify it slightly to match the current definitions in att.dimensions); make att.dimensions inherit @unit @quantity @commodity from it

  • add @commodity to att.dimensions and abolish att.measured

  • leave well alone

  • factor out @unit and @quantity (and possibly also @extent) into a new class and make the other two inherit from that

  • provide a new @SIunit attribute somewhere, constrained to be an SI unit

Discussion

  • James Cummings
    James Cummings
    2013-11-09

    In general the least backwards incompatible solution (other than doing nothing) might be to factor out @unit and @quanitity (etc.). I, separately, like the idea of an SI unit, but is there an easily testable datatype for that?

     
  • Martin Holmes
    Martin Holmes
    2013-11-11

    From TEI Council meeting 2013-11-11: "Action on MH to move @commodity into its own class, and move <measure> and <measureGrp> to att.dimensions. Ticket to GREEN, assign to MH." Changing accordingly.

     
  • Martin Holmes
    Martin Holmes
    2013-11-11

    • assigned_to: Martin Holmes
    • Group: AMBER --> GREEN
     
  • Martin Holmes
    Martin Holmes
    2013-11-13

    Subsequent thought and discussion suggests that the decision to merge @unit and @quantity from the two classes may be misguided, because the suggested value list for att.measurement is much more extensive than that in att.dimensions, and att.dimensions talks specifically of "length". We should keep them separate until we have a method of overriding suggested value lists at the element level.

     
  • Lou Burnard
    Lou Burnard
    2013-11-13

    The @unit valList for att.measurement is based on the idea that all measurements should be normalised into SIunits -- that's clearly not realistic for all the things we might want to measure (e.g. "12 hogsheads of ale"), whence my suggestion above that we should define an additional @siUnit attribute (or just drop the idea). I don't think its an argument for not merging the two classes.
    I spent several minutes scratching my head over an alternative word for "length" -- how about "extent" or "size" or "quantity" ?

     
  • Martin Holmes
    Martin Holmes
    2013-11-27

    I believe this is the perfect test case for overriding of valLists at the element level, so I believe we should keep the problem around (as an Amber ticket) until we can use it as a good test case. The obvious other case, @type, is large and complicated, so having a simple case like this to test with will probably be handy.

    Re the idea for @siUnit: given that the range of SI units is so huge, and that it also now includes non-SI units (seriously: http://en.wikipedia.org/wiki/International_System_of_Units#Non-SI_units_accepted_for_use_with_SI), I think building a plausible and practical valList would be impossible.

     
  • Martin Holmes
    Martin Holmes
    2013-11-27

    • Group: GREEN --> AMBER
     
  • Martin Holmes
    Martin Holmes
    2014-07-02

    Council 2014-07-02: Make this green again and implement now that we can.

     
  • Martin Holmes
    Martin Holmes
    2014-07-02

    • Group: AMBER --> GREEN
     
  • Martin Holmes
    Martin Holmes
    2014-08-01

    [This was also posted to the Council list]

    On the Council telco, Syd raised the issue of needing to abstract attributes from local definitions into a class, in order to provide them with the same valList in one location. Working on https://sourceforge.net/p/tei/feature-requests/470/, I've come across something slightly related.

    This FR points out that att.measurement provides for <measure> and <measureGrp> two attributes (@unit and @quantity) which are also provided by att.dimensions. Council therefore decided to do this:

    1. Move @commodity (the only other att in att.measurement) from att.measurement into a new class, att.commodity.

    2. Add measure and measureGrp to att.commodity.

    3. Add measure and measureGrp to att.dimensions.

    4. Override the definitions of @unit and @quantity on <measure> and <measureGrp> to supply suggested values that were originally part of their definitions in att.measurement.

    This seemed to be a classic case of using the new capability of overriding class attributes at the element level to improve clarity and elegance.

    If you think about it, though, by moving these attributes out of a class where they have a single valList and overriding them at the element level, we now need to define the same valList twice (once in <measure> and once in <measureGrp>) to get the same result. Now we have duplicated definitions and the consequent potential for inadvertent divergence.

    In other words, we have more rather than less complexity. I think there are only two solutions to this:

    1. We keep the current situation.

    2. We consider the possibility of a mechanism that would enable us to add att.measurement to att.dimensions, so that att.measurement inherits @unit and @quantity from att.dimensions, but overrides the definitions of the attributes at that class level (in the process adding @commodity); <measure> and <measureGrp> remain members of att.dimensions and therefore inherit the modified attributes from there.

    Thoughts? Could #2 work? Would it even perhaps work out of the box? (I'd be amazed if it didn't break DTD generation.)

    My preference would be for #1 right now, with #2 as a long-term goal after we drop support for DTDs, as part of making the class system more of a true inheritance structure. I think it would be really useful to have the ability to define attributes with successive levels of specificity, with elements having the ability to select a particular version of an attribute from a particular class at any point in the tree. For that reason we could set the ticket to red to keep it around as a test case for such future developments in ODD.

     
    • On 1 Aug 2014, at 16:15, Martin Holmes martindholmes@users.sf.net wrote:

      • We consider the possibility of a mechanism that would enable us to add att.measurement to att.dimensions, so that att.measurement inherits @unit and @quantity from att.dimensions, but overrides the definitions of the attributes at that class level (in the process adding @commodity); <measure> and <measureGrp> remain members of att.dimensions and therefore inherit the modified attributes from there.

      Thoughts? Could #2 work? Would it even perhaps work out of the box? (I'd be amazed if it didn't break DTD generation.)

      It would be interesting to see this written out in long hand in ODD code, and tested against the existing
      implementation. ‘snot impossible it would work in RNG/XSD land. DTDs, let’s not worry about for now,
      much more concerned that the notation seems like believable ODD.
      --
      Sebastian Rahtz
      Director (Research) of Academic IT
      University of Oxford IT Services
      13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

      Não sou nada.
      Nunca serei nada.
      Não posso querer ser nada.
      À parte isso, tenho em mim todos os sonhos do mundo.

       
  • Lou Burnard
    Lou Burnard
    2014-08-01

    The problem with the current situation is that we would still have too many classes. So my suggestion would be:
    - drop att.measured
    - add @commodity to att.dimensions
    - define a new SIunit attribute in att.dimensions with an appropriate valList
    - add a schematron rule to permit either @SIunit or @unit but not both

     
  • Martin Holmes
    Martin Holmes
    2014-08-01

    We've already had the discussion about a valList for SI units (see previous posts on the ticket). I'm certainly OK with having @SIUnit (how exactly should that be capitalized?), but I don't think the valList is practical.

    There's also the issue of all the existing members of att.dimensions now getting @commodity -- this includes (again as discussed two or three times) <sex>, <population>, <persName> and many other elements on which it will be ludicrous.

     
  • Lou Burnard
    Lou Burnard
    2014-08-01

    Sorry, I missed the discussion of SI units on the ticket, I agree -- forget that idea! (though it might be worth having some way of saying whether or not your @unit values are actually in SI units)

    As regards @commodity on <sex> or <persName> -- I agree it's ludicrous, but so are many many others. All the class memberships for those state/trait elements are a mess, which I think another ticket is supposed to be looking at.

    Let's stick with your proposed option 1 (do nothing) for now!

     
  • Martin Holmes
    Martin Holmes
    2014-09-09

    I'm going to set this to red, since it looks like there is no useful solution while we continue to support DTDs. We can keep it around as a test case for future ODD work after we're free of DTDs.

     
  • Martin Holmes
    Martin Holmes
    2014-09-09

    • status: open --> open-later
    • Group: GREEN --> RED