On Thu, 9 Sep 2004, Syd Bauman wrote:
> I am *so* glad this has been brought up. While I believe it is
> essential that there be a mechanism to indicate which of the
> <abbr>/<expan> children or generic <seg> children of a given instance
> of <choice> was in the source, I am not at all sure I've come up with
> a good one here.
> So far:
> * src= of <choice>
> * eldest sibling
> * resp= on one of the children
> * something_else= on one of the children
Other alternatives could include a <lem>-like element, bu I think
we discarded this idea earlier, and I understand why it would make
people feel uncomfortable.
Though, to be honest, I suppose one knows that is an abbreviation
because of the use of <expan> .... hrmm. I suppose the same is
true for when <corr> and <reg> are used, they naturally imply
that the <lem>-like element would be <sic> and <orig>. I suppose
one option is some terrible expansion of the use of <orig>. I don't
feel very comfortable with that, but thought I should voice it to be
> src= has the advantage of being quite easy to describe and use, and
> is quite clear. Has the disadvantage that with DTDs, and probably
> even in RelaxNG, we won't be able to schema-enforce the restriction
> against using it when the children of <choice> are not <abbr>/<expan>
> or <seg>.
I know P5 backwards compatibility with DTDs will not be entirely
possible, but where it is, I think that should at least influence our
> I share Sebastian's vague misgivings about using sibling order, but
> since I can't really say why, would be willing to go with that if
> that were the will of the many.
Well, the reason I also feel a bit uneasy about it is I can see easy
slippage (by myself!) into using it not to indicate relationship with
the original, but processing preference.
> Although I don't think it's as bad as James makes it sounds, I think
> he is right, overloading resp= is probably not the best thing to do.
Well, maybe I was exagerating a bit. But I was picturing a manuscript
page of accounts with each entry by a different scribe, and without
lots of use of 'hand' and such expanding the abbreviations with that
method would be painful.
> Another attribute added to <abbr>, <expan>, and <seg> may be a very
> reasonable solution. We have a similar difficulty schema-enforcing it
> (the attribute would make no sense, e.g., if the element in question
> is not the child of a <choice>).
Agreed, that is a problem.
> I mildly prefer the attribute on <choice> over the attribute on a
> child because I think the "which was on the source" as a feature of
> the encoding of the multiple streams, not of the child element that
> makes some semantic claim about one of those streams.
Hrmmm. I must be picturing this from a different angle. It seems
very strange to me to have as an attribute value the name of an
element child. It gives me the same kind of misgivings that
enforcing position order does. I see one of the elements sticking
out its hand (ok, attribute value) saying "I'm the original one", rather
than <choice> saying "The original one is named 'abbr', go find it".
> While we certainly could use some other mechanism besides naming
> elements in an attribute of <choice>, I do not find the argument here
> against persuasive at all. First off, who says that processing has to
> be by name and not function? And if it is on name, who says the match
> is against the GI rather than the TEIform= or the ident=? But more
> importantly (given that many people will want to process by name
> against GI), if you rename <abbr> without renaming the attributes'
> values, you should expect trouble, just as if you'd changed the name
> of <persName> to <name-of-person> but left the assertedValue= of
> <certainty> and the gi= of <tagUsage> as "persName". (In these cases
> too, one could argue we should be looking at TEIform=, not the GI.)
I thought Sebastian's objection might come into play with multilingual
markup. i.e. if you translate <abbr> then for processing implications
src="abbr" must be the same. But I suppose that isn't much of an
obstacle since these should be the same in any case, just a renaming
of attribute value when translating documents.
> However, there are probably other reasons that using a pointer (as
> with <seg>) or a serial count (which I have the same vague misgivings
> about as sibling order) as the value of an attribute on <choice>
> would be better.
Though, there is an argument here for simplicity as well. If I'm going
to be using <choice> hundreds of times on a single page, I want it to be
as straight-forward to use as possible. I'm sure you guys understand
the technical details of all the multiple possibilities better than
I do. I simultaneously want <choice> to be a robust and extensible as
possible, but simple to use.
Dr James Cummings, Oxford Text Archive, University of Oxford
James dot Cummings at oucs dot ox dot ac dot uk