[tei-council] more class rationalizations

[James Cummings]

What they all said. ;-)

Seriously though, the customisation of @type on att.segLike is primarily 
to provide the following descriptive text isn't it?

"For a cl may take values such as finite, nonfinite, declarative, 
interrogative, relative etc. For a phr or w, values such as noun, verb, 
preposition, etc., may be used. For an m element, values such as clitic, 
prefix, stem will be more appropriate. For a c element, values such as 
letter, punctuation, digit may be used."

Can we preserve this helpful text in association with @type on these 
elements? However, anywhere we have @typed it just makes sense to have 
@subtype to me.

According to:
http://tei.oucs.ox.ac.uk/P5/Guidelines-web/en/html/REF-ATTS.html

@subtype is only available on att.typed elements and seg. (which will be 
just att.typed elements after you've made this change).

@type on the other hand is available on:

att.entryLike att.interpLike att.pointing att.segLike att.textCritical 
att.typed abbr  app  biblScope  castItem  classSpec  constitution 
derivation  dimensions  distinct  divGen  domain  factuality  forest 
forestGrp  form  fs  fsDecl  fsdLink  fw  geogName  gram  graph  iType 
idno  interaction  lbl  list  macroSpec  measure  metDecl  moduleSpec 
move  node  note  num  oRef  oVar  orth  preparedness  purpose  q 
recording  relation  sound  stage  tag  tech  teiHeader  title 
titlePage  titlePart  usg  valList  witDetail  xr

Now, I know some of these are because we provide a suggested value list 
or similar for the @type on that element.  Are there any that could just 
be rolled into having att.typed instead?

Or is the problem that hoary chestnut of wanting to be able to provide 
att.typed but then override the value list, or descriptive text only for 
a particular element's definition?  (Something I'd see as a good thing 
if possible.)

Of the above list those where we *don't* provide a list of suggested or 
required values (but often do change the descriptive text about what 
@type means) and potentially could just use att.typed in my mind include:

att.pointing, att.segLike (@type to be removed), app, distinct, forest, 
forestGrp, fs[1], fsDecl, fsdLink, geogName, idno, lbl, measure, 
moduleSpec[2], note, orth, sound, titlePage, and witDetail.

For none of these do we provide suggested or required values delineated 
in the ODD.  In some cases we do so in the descriptive prose that 
accompanies this attribute.  e.g. titlePage/@type has:
"Any string, e.g. full, half, Series, etc."  But this kind of vague 
suggestion is also made on others where we actually provide a value list.

I simply mention this if it is of any help in deciding whether these 
other elements should be made members of att.typed or in kick starting 
discussions about the revising of ODD.

-James

[1] http://tei.oucs.ox.ac.uk/P5/Guidelines-web/en/html/ref-fs.html the 
suggested value for @type in this instance is wrong because it contains 
whitespace!
[2] "A closed set of keywords yet to be defined" is not very helpful!



Arianna Ciula wrote:
> Agree.
> 
> Arianna
> 
> laurent.romary at loria.fr wrote:
>> I am just amazed that we still have such a legacy situation...
>>
>> It is a clear go-ahead from me!
>>
>> Lou's Laptop <lou.burnard at oucs.ox.ac.uk> a écrit :
>>
>>> I'd be very grateful for comments from council members on whether or not
>>> to press ahead with the minor tweak proposed in SF bug #2161974
>>>
>>> Text of this bug says: "
>>>
>>> The members of att.segLike (cl, c, m, phr, seg, s, w) all inherit their
>>> @type attribute from that class, rather than from att.typed. Consequently
>>> they don't behave like other typed attributes, which inherit this
>>> attribute from att.typed. Thus most of them don't have a @subtype
>>> attribute (except for seg, which adds it explicitly) This seems
>>> confusing and inconsistent. I propose to remove the @type attribute from
>>> att.segLike, remove @subtype from seg, and add all these elements to the
>>> att.typed class.(Another solution might be to make att.segLike a child
>>> of att.typed, but I prefer the more
>>> explicit one suggested here)"
>>>
>>>
>>> Can anyone suggest a good reason not to do this?
>>>
>>>
>>> _______________________________________________
>>> tei-council mailing list
>>> tei-council at lists.village.Virginia.EDU
>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>>
>>
>>
>> _______________________________________________
>> tei-council mailing list
>> tei-council at lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
> 


-- 
Dr James Cummings, Research Technologies Service, University of Oxford
James dot Cummings at oucs dot ox dot ac dot uk