Menu
▾
▴
#259 normalize attributes and classes on placeName/geogName
closed-accepted
5
2011-12-02
2011-03-16
No
I just received a request for tei:geogName to allow @cert (as tei:placeName does); this seemed a reasonable feature request to me, but before I posted it, I checked the two elements and found that their attribute class memberships were remarkably different. I can't see any good reason why any attribute available on placeName should not also be available on geogName. They are after all very very close to meaning the same thing.
As far as I can see, normalizing this would not harm geogName in any way (in fact it would require one less bespoke attribute: @type).
Any objections?
The att class memberships of these elements is probably due for a careful check and tidyup, but the general principle is that the lower level components of names don'get encumbered with the same attributes as the upper ones, so as to avoid the possibility of contradicting one self. For example <surname> doesn't have all the same attributes as <persName> -- rightly or wrongly the same model applies to <geogName> which is regarded as being a lower level component than <placeName>, presumably because the same placeName might contain both a geogName and a <country> etc. Arguably this is wrong, but that's the logic.
Agreed to add geogName to same att classes as placeName, modulo observation that att.dimensions seems very implausible (but it's on several others)
As agreed at Council mtg in Mov 2011, added geogName to same att classes as placeName. Implemented at rev 9866