[tei-council] attribute/datatype data updated

[Syd Bauman]

James, thanks so much for the thoughtful feedback!


> Why is tei.data.duration set up defaultly not to allow plurals?
> Things take 3 weeks (or longer :-) ) not 3 week. I think in
> addition to wk/yr/week/year/month there should be
> wks/yrs/weeks/years/months. I would abbreviate month as
> mnth/mnths, if I did at all.

I thought about this for only a few seconds, and thought that the
unit being used is a thing, in the singular, of which there may be
multiples, which cause us to use the plural. More importantly, the
capability to use the plural only makes sense for those which are
derived from abbreviations of English words: year, month, and week.
Everything else is a symbol from Comité International des
Poids et Mesures, and as such is really already plural, and can't be
expressed with an "s" appended. (The speed limit is 100 km/h, not
kms/hr.) 

Should there be plurals for year, month, and week? (I don't think I
care.) Should we bother with abbreviations of those three? (It's
easier for the editors if we don't :-)


> @calendar = What about Lunar & Solar (as more vague types of
> astronomical?), Gregorian? I believe the Tibetan calendar is
> different from the Chinese one. I would personally like 'Regnal'
> since many of the dates I've used are in an English Regnal
> calendar. (I.e. 5 Edward III for the 5th year of the reign of
> Edward III). 'Fiscal' could be another type of calendar, since that
> fixes each month a a specific number of weeks to facilitate
> economic comparisons. Maybe 'Liturgical'...but there are different
> ones depending on faith. There are others at
> http://en.wikipedia.org/wiki/List_of_calendars

All good suggestions, I think. Is there a more definitive list
somewhere that we should use as a basis?


> @character on <hand> Are 'Shaky', 'Thick' and 'Regular' the
> appropriate palaeographic terms? I realise it has tei.data.token as
> well, but surely something can be 'Thin' but not 'Shaky'? (Sounds
> like milkshakes...)

I certainly don't know. I just copied the list from the "suggested
values include" in the tagdoc.



> @cols/@columns = I've not looked at this at all, but it just seems
> strange that these are different datatypes. 

Oh dear. These three are completely screwed up. I'll fix 'em right
after dinner.


> @date on <birth> = Why not tei.data.temporalExpression?

This is what we call in the encoding world an "error". As is obvious
by the additional constraint, it's supposed to be
tei.data.temporalExpression. 


> @ed on <milestone> = point to xml:id on <text> maybe?

Won't work in the general case of having more than one edition
encoded in the same file. There are a lot of ed= attributes that need
to refer to a controlled vocabulary. I think we need to create an
<edList> or some such in the <teiHeader>.


> @feature on <shift> = should include tei.data.token ?

I'm inclined to think so, but again, I was just copying what is
currently present in the declaration of that attribute.


> @form on <biblItem> = Should other formats be included? video.MPEG7
> audio.MP3? Or does this relate only to the physical form? Also,
> what about 'webpage'?

I think only physical form, but to be honest, not only don't I know,
I don't think it has been thought through very thoroughly yet by
anyone. 


> @place = Should these include tei.data.token for transcriptions of
> non-standard objects?

(I presume you mean of <add>, <addSpan>, or <fw>.) Same answer as for
feature= of <shift>, I think.


> @type on <abbr> = ugh. ... Is the list allowing just one of each
> of these values, or can something be suspension and contraction?

I'm really not sure what is the right way to go with this one. I
suspect that in the end, we'll need to use a looser model than the
one I've sketched (the values for which were pretty much copied from
the current declaration, BTW), if for no other reason than ODD won't
be able to support this kind of thing, it least not soon enough for
immediate use.

However, that said, I think it *is* useful to think about the
semantics of type= of <abbr>, through its syntax, even if we end up
loosening the syntax later.

Here's what I sketched out, with whitespace improved for (human)
readability: 

| list { 
|      ( "suspension" | "contraction" | "brevigraph" | "acronym" | tei.data.token )?,
|      ( "superscription" | tei.data.token )?,
|      ( "title" | "organization" | "geographic" | tei.data.token )?
|      }

This means 0 or 1 from each group, in the order specified. So
  type="suspension superscription title"
  type=""
  type="acronym organization"
are all valid even if you removed the "tei.data.token"s, but
  type="title contraction"
would not be. With the "tei.data.token"s there, the only constraint
is that there be no more than 2 internal sequences of whitespace.
I.e., 
  type="a b c"
is OK, but 
  type="a b c d"
is not.

> Shouldn't 'acronym' go into the list with title/org/etc. since is
> both the reason for an abbr while also the method? 

I have to admit, I hadn't thought of acronym as a reason. (This
from the guy who came up with "consideration, resolution, and
progress". :-)

> Why is superscription by itself?

Seemed to be in a category by itself. But I think the real question
is why is superscription in the list of values at all? Seems like a
detail best left to rend= to me.


> @type on <camera> = Should possible values use industry standard
> abbreviations or be human readable:

Darn good question, to which I don't have an actual answer. But I
think one guideline for us to apply is that brevity is not itself a
goal unless the value is going to appear a lot, in which case it can
become pretty important. (E.g., if <cit> were called <citation>, it
wouldn't be much of a loss, because it doesn't generally occur very
often; if <lb> were called <line.break>, it could get really annoying
really fast.)


> @unit on <milestone> = 'folio'?
> 
> @value on <date> = why tei.data.pointer? I must not understand how that works.

Nope, you understand, you've just stumbled into another error.


> @zone = tei.timezone ?

Yes, personally I think that since there are 2 zone= attributes and
the list of timezones is potentially a pain to maintain, it may make
good sense to give this one its own datatype, 'tei.data.timezone'.


> Just things which occurred to me while scanning through,

I'm glad you scanned! Thanks. I hope to send a repair report in an
hour or so.