free-standing attributes -> class

[TEITechnicalCouncil]

Now that local modification of class attribute is supported at the source level, we need to make a new catalogue of all attributes which have the same name as ones in classes, and which can therefore be considered as amenable to being expressed as a local modification. There are, for example, apparently 69 attributes called 'type' - most of these can very likely be turned into membership of att.typed.

Original comment by: @sebastianrahtz

[TEITechnicalCouncil]

This issue was originally assigned to SF user: pfschaffner Current user is: pfschaffner

[TEITechnicalCouncil]

I just note that @type is really the only significant case of this kind

Original comment by: @lb42

[TEITechnicalCouncil]

well... there are 58 occurrences of attribute names used more than once on elements, and about 20 of those also appear in classes. http://tei.oucs.ox.ac.uk/atts.html contains the damning evidence. @scheme, @target, @value, @name, @key seem ripe for examination.

so depends on what the definitiin of significant is :-}

Original comment by: @sebastianrahtz

[TEITechnicalCouncil]

Assigning to rahtz to bring a proposal to Council of what attributes should change. Setting as AMBER since this will need discussion. The general idea is, of course, a good one and why we introduced this facility.

Original comment by: @jamescummings

[TEITechnicalCouncil]

• milestone: --> AMBER
• assigned_to: nobody --> rahtz

Original comment by: @jamescummings

[TEITechnicalCouncil]

the requested catalogue is at http://tei.oucs.ox.ac.uk/duplatts.html, showing 49 cases to consider. I think they are all open to discussion. @type is the big one, but plenty of others are in double figures.

Original comment by: @sebastianrahtz

[TEITechnicalCouncil]

Gawd. I see both @target and @typed are in more than one attribute class. Are we thinking that an attribute class can be a local modification of another attribute class?

Original comment by: @martindholmes

[TEITechnicalCouncil]

"Are we thinking that an attribute class can be a local modification of another attribute class?" - thats getting tricky. Its a possibility, but first we need to decide if they are in fact the same concept. Getting to grips with all the uses of @type is a serious undertaking :-{

something like @hand or @wit is easier to sort out

Original comment by: @sebastianrahtz

[TEITechnicalCouncil]

As I suggested above, @type is probably the only really significant problem area. Most of the others are easily resolved. When resolving them though, I am worrying that we will often be adding irrelevant attributes just for the sake of tidiness. In at least some cases where @x is defined locally rather than inherited from att.whatever, it's because att.whatever also supplies attributes @y and @z which are not relevant. Do we really want to make loads of subclasses?

Original comment by: @lb42

[TEITechnicalCouncil]

You can have a local modification to remove unwanted attributes, but when I proposed and did this in 2012, I got burnt at the stake for heresy by some people. I am not we ever resolved it after an argument in Ann Arbor.

Original comment by: @sebastianrahtz

[TEITechnicalCouncil]

I have made a first stab at an inventory of free-standing instances of @type in a Google Doc. Confirmation of or disagreement with my recommendations is welcome.

https://docs.google.com/spreadsheet/ccc?key=0AtV1qdTijAwLdDBPay1vLVh6Q2dOS19JdkUwUkhibmc&usp=sharing (anyone with the link should be able to comment; let me know if you wish to be able to edit)

Original comment by: @rwelzenb

[TEITechnicalCouncil]

can you remove forest and forestGrp from list? I have moved them to att.typed willy-nilly.

Original comment by: @sebastianrahtz

[TEITechnicalCouncil]

• assigned_to: Sebastian Rahtz --> Rebecca Welzenbach
• Priority: 5 --> 1(low)

Original comment by: @sebastianrahtz

[TEITechnicalCouncil]

Per Council discussion in Oxford, we decided that once this is implemented, we need to add a note to att.typed reminding people that this is meant to describe the type of element, not type of scope, function etc.

Original comment by: @kshawkin

[TEITechnicalCouncil]

Good luck enforcing that... ;-)

Original comment by: @bansp

[TEITechnicalCouncil]

• assigned_to: Rebecca Welzenbach --> Paul Schaffner

Original comment by: @jamescummings

[TEITechnicalCouncil]

Reassigning to PFS to follow up

Original comment by: @jamescummings

[sydb]

Council makes GREEN for @emylonas and @sydb to at least scope out the size of the problem — how many attributes are there to worry about? — if not address the attrs themselves.

[sydb]

We (Syd & Elli) have scoped out the size of the problem. We re-wrote P5/Utilities/listduplatts.xsl. The output can be seen on Syd’s basement server. We propose to go through the list (perhaps with help — anybody?), picking off the easy ones first, in the near future (measured in weeks to months, not hours to days:-). Each duplicated attribute should be classified as

1. should remain locally defined
2. should become member of an existing attribute class
3. should become (possibly along with other locally defined instances) member of a new attribute class
4. should become member of an existing attribute class but its description may need more detail than is provided in the class description.

In the last case, we can either try to reword the class description to account for the special case, keep the locally defined attribute (thus making it the first case), or develop a feature of ODD that allows an element to belong to an attribute class, but to over-ride the description.

[lb42]

This is a nice table but it would be even nicer if it showed what other attributes are provided by the attribute class cited. This is because the decision to locally define an attribute may be based on the desire to avoid festooning it with irrelevant attributes provided by the class.

[emylonas]

regenerate table. @emylonas and @sydb do @type as trial balloon for how to go about this and then divvy it up

[sydb]

Reminder to @emylonas and myself not to forget @type of <tech>. See #1662.

[emylonas]

Syd and I have been going through attributes that are not already in a class with other attributes that have the same name. We are looking to see if they should be added to the class or not.

We have the following cases

1. The attribute should be added to an existing class, but might have a modification to its definition in order to provide some more specific wording

2. The attribute is completely different from any attribute class, and we should leave it alone.

3. The attribute is quite similar to the definition of the attribute class containing attributes with the same name, but modifications are necessary.

Note that before changing anything it is necessary to look at other attributes that the class might bestow, as well as other attributes that an element already has.

Our question to the Council is: Do we prefer adding attributes to classes with local modifications? Or allowing attributes to stand alone even if they are related to an attribute class. How much modification is ok?

preliminary disambiguation here: https://docs.google.com/spreadsheets/d/1k6rB7SSvWlZQKtOFDUJhpNVUDcNM8xETlWWiH3JAYZw/edit?usp=sharing

[emylonas]

Although no longer on Council, I'm willing to try and manage this ticket