[tei-council] notated music

[Lou Burnard]

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.
>
> G
>
> 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
>> uncontroversial.
>>
>> -James
>>
>