[tei-council] Topics for discussion

Mon Sep 13 16:25:00 EDT 2004

Apologies for a lengthy and tardy post. I've looked through all of 
the suggestions. The ones that Syd posted I won't comment on, except 
to say I support them all (having been involved in their evolution). 
If anyone has questions of the "why on earth" variety about these, I 
can probably provide specifics.

On the others, several seem like very good ideas:

--publisher children/requiring explicit relation between publisher and pubPlace

--Hilde Boe's suggestions  on manuscript encoding, and the realRhyme= 
attribute; I can't judge the usefulness of the an= and realAn= 
attributes.

--improve handling of letters: this seems like a high priority to me. 
Could we give Nick and Edward an official commission to come up with 
a proposal?

--names/prosopography module: this seems like a good idea. I'd also 
like to propose that <partic> and <particDesc> be designated for use 
not just in describing speakers in a linguistic corpus, but also more 
generally any participant in the document's creation/production/etc. 
In other words, if I want to document demographic info on a set of 
authors, editors, translators, even printers and publishers, this 
would be a logical place to do it.

--adding namespace info to <tagUsage>: the goal is clearly important. 
I like the <nameSpace> element as a wrapper around <tagUsage> 
elements, not least because we could also provide therein a place to 
provide info about that namespace. I think we could even require this 
element (rather than allowing it to be optional and assuming TEI 
namespace in its absence); this will be the least of people's 
conversion challenges when they go to P5. As an alternative, wouldn't 
a namespace= attribute on <tagUsage> do the trick? Are there 
significant advantages to grouping all the elements from a given 
namespace within a wrapper?  As an addendum: I would suggest that we 
drop the requirement that there be a <tagUsage> element for every GI; 
the useful functions of <tagUsage> these days seem to me to be 
rendition and documentation; verification of the number of elements 
seems a little old-fashioned.

--revision of <figure>: seems good to me, but I'm not sure I 
understand the proposal exactly--is the <figDesc> element intended to 
appear both within <figText> (which would have the content model of 
current <figure> element) and also as a direct child of <figure>? 
Also: the current content model of figure doesn't allow for the fact 
that text (including poetry) may appear both/either above and below 
the graphical content of the figure. It would be good to be able to 
accommodate this fact. It's also good to preserve the current 
distinction between the text that accompanies the figure (headings, 
captions, etc.) and text that is actually embedded within the image 
content (e.g. speech ballons, painter signatures, banners, signs, 
etc.).

Some seem like interesting ideas that aren't fully perfect, or aren't urgent:

--Andrea Nolda's thoughts on inline, displayed, and floating 
elements: I sympathize with the goals of this one, but I'm not sure 
it's a good thing for TEI to specify default rendering behavior. This 
seems like something that should be handled by allowing authors to 
set renditional defaults, and this is already possible in TEI with 
<tagUsage>. For the rest, I disagree with him, I think things like 
what to do with the value of n= *should* be left to the stylesheet, 
and the author is free to create such a stylesheet if he/she wants to 
constrain the appearance of the document.

--the accept= attribute on <mentioned>, <gloss>, and <seg>: it seems 
to me that if the symbols are to stand just as symbols, they should 
just be encoded as renditional facts. If the problem is that there's 
no consensus about the symbols to be used and their interpretation, 
perhaps the better thing would be to bypass the symbols and allow the 
accept= attribute to have a set of specific values (more nuanced, by 
the looks of things, than "yes | no") which represent a superset of 
the values/interpretations currently in use, allowing the user to 
employ a subset as appropriate. Then the symbols could just be 
rendered with a stylesheet. I don't think having an accept= attribute 
with values "* | ? | ?* | (?) | #" etc. is such a great idea. But 
this isn't an area I'm familiar with, so I'm going on logic, not 
experience.

--type= on <mentioned>; I'm susceptible to this because I believe 
type= is so generally useful. It doesn't seem overwhelmingly urgent 
to me, or likely to affect a lot of users, but I can see the utility.

--revision of <index>; this seems confused to me. If the <index> 
element is intended to mark the point in the flow of text where the 
index entry points, this doesn't seem like a good place to put 
information about how the index entry itself is going to look (e.g. 
"see also" references, etc.). Surely the point is that some software 
comes along and gathers up all the <index> elements and processes 
them into an index entry. No single <index> point can be expected to 
carry the extra information for the entry itself. I think the problem 
is real--this extra information is needed--but packing it into 
<index> doesn't seem like a good approach. I also don't see the 
function of the <indexContent> element; is its content intended to 
become part of the index entry, or is it just the basis for a link?

--add <label>/<eLabel> to <eTree> etc.: seems reasonable to want to 
have content/markup in a label

--make <interp/> non-empty to allow for values with internal markup: 
seems reasonable.

--add <measure> to the typed class to allow for subtype=: I agree 
with the basic idea here, but I wonder whether a unit= attribute 
would be better than subtype=; it would more explicitly capture the 
semantics of what John Walsh seems to be after. I also wonder (while 
we're on this) whether it would be better to have the number as a 
separate attribute, rather than including it as part of the reg= 
attribute.

--generic <metadataItem> element in header: I'm on the fence about 
this. I guess it's the equivalent of providing <div> and <ab> and 
<seg>; why shouldn't there also be a generic metadata element in the 
header? But I also feel as if we should be attempting to provide for 
all the reasonable classes of metadata in a more specific way. In 
other words, this shouldn't become the dustbin where we put metadata 
ideas that don't fit into the existing TEI header. The prospects for 
interchange with this generic element seem pretty poor.

Possibly unnecessary?

--Hilda Boe's suggestion for extending metrical analysis of verse: 
doesn't the realMet= attribute duplicate the functionality of the 
existing real= attribute?

Best, Julia

>At our next phone call, scheduled for 20 Sept, it would be very 
>helpful if council members could give some initial comments on the 
>various suggestions for enhancements which have so far been 
>accumulating on sourceforge. I was going to attempt a summary of 
>them all, and can easily produce a list if so required, but 
>discussion will be much more productive if council members have 
>already read at least some of the arguments before hand.
>
>The easiest way of doing this is for you to point your browser at 
>http://sourceforge.net/tracker/?atid=644065&group_id=106328&func=browse
>
>(or navigate to the "feature requests" from http://tei.sourceforge.net)
>
>If you want to add comments on any item (or add new items) before 
>the meeting, that would also be much appreciated!
>
>I am also working on a document 
>(http://www.tei-c.org/Drafts/edw83.xml) which attempts to summarize 
>all other "work in progress" for P5. This is far from complete, but 
>I hope to get it into better shape in good time for the phone call. 
>All input gratefully received!
>
>Lou
>
>
>
>
>
>_______________________________________________
>tei-council mailing list
>tei-council at lists.village.Virginia.EDU
>http://lists.village.Virginia.EDU/mailman/listinfo/tei-council