[tei-council] notated music

[Martin Holmes]

On 11-07-04 09:16 AM, Lou Burnard wrote:
> I think that #3 is clearly necessary, #1 is debatable, and #2 is
> something that needs a lot more discussion

But if #3 is syntactic sugar for #2, shouldn't we deal with #2 first? We 
can't detail the semantics of <notatedMusic> as a special case of 
something else when we haven't yet created the something else.

Or do you think it's better to create <notatedMusic> first, and work out 
the semantics of its parallel content, and then use that as the basis 
for a more generalized element at a later date? That does seem 
topsy-turvy to me.

Cheers,
Martin

>
> 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
>>>
>>
>
> _______________________________________________
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> PLEASE NOTE: postings to this list are publicly archived
> .
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)