[tei-council] notated music
lou.burnard at retired.ox.ac.uk
Mon Jul 4 12:16:27 EDT 2011
I think that #3 is clearly necessary, #1 is debatable, and #2 is
something that needs a lot more discussion
I assume that the three are disjoint.
On 04/07/11 17:08, Gabriel Bodard wrote:
> I don't think that #2 and #3 are necessarily the right way around in
> this suggestion, both for the reason that James mentions, and because we
> don't necessarily have a problem of creating a general class of things
> when a specific instance of it already exists. We have a concrete and
> uncontroversial use-case for *tei:notatedMusic, whereas the more general
> container is currently a more woolly concept that could probably stand
> to be discussed and consulted on a bit more widely.
> I vote we go ahead with #1 and #3, and think about #2 some more.
> On 2011-07-04 16:52, James Cummings wrote:
>> On 04/07/11 16:34, Martin Holmes wrote:
>>> I don't want to block this, but I do think we might be doing several
>>> things at once here. There seem to be three distinct issues:
>>> 1. The need for an<externalObject> (or whatever) which is specifically
>>> designated as a transclusion element.
>>> 2. The need for a container element whose content elements are deemed to
>>> be not choices exactly but somehow parallel renderings in different
>>> formats of the same content (an image of notated music, an XML rendering
>>> of it, an MP3 file of the music). This contrasts with<choice>, which
>>> apparently assumes that one of its content elements will be chosen in
>>> any given context.
>>> 3. The need for<notatedMusic>, which is semantic sugar for
>>> <aboveContainer type="notatedMusic">.
>> I agree with this, except for the assumption about choice which
>> is tangential here. (For the record, I feel choice is probably
>> misnamed because in most processing of it these days we do *not*
>> make the choice... we might privilege one over the other, but in
>> most renderings I've seen both are available in some way (often
>> able to be toggled or present in a tooltip etc.). This is
>> exactly what I usually do with choice. But none of this matters
>> for this discussion.
>>> If my understanding above is correct, then I think it would be better to
>>> make three separate feature requests, and deal with #2 before #3. Or am
>>> I missing something?
>> Nope, that sounds correct to me. My only worry is that #2 is
>> likely to cause much discussion whereas in general #3 is fairly
More information about the tei-council