As a result of the att.editLike attribute class containing both att.dimensions and att.ranging, a large number of elements which do not really have numerical values or content that needs to be expressed as numerical values, are acquiring attributes such as @atLeast, @atMost, @min, @max, @quantity, @extent, @precision. To my mind, the following elements should not have these attributes (for what on earth would they mean?):
add; del; addSpan; delSpan; restore; subst; corr; reg; unclear; expan; origPlace; origin; ex; am; supplied; surplus; orgName; persName; placeName; affiliation; climate; event; faith; langKnowledge; langKnown; location; nationality; occupation; org; person; place; relation; residence; sex; socecStatus; terrain.
How to fix this requires some discussion, however, since there are several elements (gap, space, date, time, origDate, age, birth, death, floruit, population, state, trait) which inherit these attributes and arguably should do so.
Presumbly the solution to this is (1) to remove att.dimensions and att.ranging from att.editLike, and (2) add them instead to those specific elements to which we think they belong. Any objections?
My suggested list above should probably be discussed in some detail at the next F2F, to make sure I'm not missing anything obvious.
Agreed that these elements need to be re-classified.
Gaby agrees to submit a more detailed proposal.
Concretely, I propose that we:
gap, date, time, origDate, age, birth, death, floruit, population, state, trait
which previously inherited it from att.editLike, so that they continue to have the attributes available.space
for consistency with the above.This will have the effect that the following elements no long inherit att.dimensions, but I assert that they never should have in the first place:
corr, reg, unclear, name, expan, origPlace, origin, ex, am, supplied, surplus, orgName, persName, placeName, geogName, affiliation, climate, education, event, faith, langKnowledge, langKnown, location, nationality, occupation, org, person, place, relation, residence, sex, socecStatus, terrain.
If there are any elements in the latter list that anyone strongly feeds should inherit att.dimensions, we can add them as per the steps above. Any objection? Should we canvass for anyone this change would hurt, before making it?
Last edit: BODARD Gabriel 2013-06-18
I think the change is good, but it would be worth running it by TEI-L
just to be sure no-one will get bitten by it. I can imagine (for
instance) someone using @precision on
<population>
.Cheers,
Martin
--
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes@uvic.ca)
Last edit: BODARD Gabriel 2013-06-18
Yes,
<population>
is one of the elements I propose continuing to allow att.dimensions on, not losing it. The rationale being you would expect the content of this element to have a numerical component. I can't envisage such a component on the elements in the second list. (But you may be right that a message to TEI-L wouldn't hurt.)In my opinion, @dimensions make sense on transcriptional elements, such as
<add>, <delSpan> or <surplus>
, etc. to encode the size of the affected text span in a convenient manner. I actually use @unit ('word' or 'chars') and @quantity on<surplus>
in the Quest of the Holy Grail digital edition (http://txm.ish-lyon.cnrs.fr/txm/) to generate notes like "3 mots répétés" when appropriate.Of course, this is redundant, as the information can be calculated by analyzing the number of characters or word tokens inside
<surplus>
but removing these attributes will make my work much harder.Agree : assign to MH to ask Gabby to implement.
Council would like Gabby to go ahead and implement this (or pass it to me if he doesn't want to).