[tei-council] <notatedMusic> changes required

[Martin Mueller]

But what is it that "the MEI folks want to do with it after all?" I looked
at a reference that Raffaele sent me, but I didn't find it entirely
conclusive or intelligible.  Would it be helpful if somebody did some kind
of two-column explanation where the left column described in the language
of laymen or musicologists what is wanted and the right column gives a
technical account of the options that exist?

>From following the discussion on the list -- perhaps not as carefully as I
should -- I do not have an answer to as basic a question as this: "is
there a music specific problem here that requires a music specific
solution?"



On 7/9/11 1:53 PM, "Gabriel BODARD" <gabriel.bodard at kcl.ac.uk> wrote:

>So based on what you suggest below, I would argue that what you need is
>a way to indicate whether what you are pointing to is (a) a
>representation of the music notation in your source document, which may
>be an image or MEI XML, say, or (b) a different kind of rendering of the
>musical information in that document, such as a recording or performance
>of said music. The difference between pointing to an image and pointing
>to an XML file or web page should be the difference between <graphic/>
>and <ptr/>, shouldn't it?
>
>Which of the above uses (if any) is the proposed <externalObject/> meant
>to cater for?
>
>My concern with the x-include suggestion is that this is no longer
>semantically describing what is in the source document at all; it is
>explicitly a processing instruction saying, go find the code at this
>location and include it in this XML document prior to transforming it.
>And this not be what the MEI folks want to do with it at all. (After
>all, if they did, wouldn't they just include the XML in this document?)
>
>G
>
>On 08/07/2011 22:45, Sebastian Rahtz wrote:
>>
>> On 8 Jul 2011, at 21:02, Martin Holmes wrote:
>>
>>> I think if you spend a lot of your time writing rendering code -- i.e.
>>> turning TEI code into other formats which will be consumed by readers
>>>--
>>> then it's tempting to see all TEI elements has having or needing some
>>> kind of intrinsic expected rendering behaviour; when you're writing the
>>> TEI stylesheets, you're essentially codifying those expectations.
>>
>> Yes indeed, I fully admit admit my bias. But to turn that around,
>> if I can't interpret a file in a standardized way, its not
>>interoperable,
>> so whats the point of it?
>>
>> If we have no expectation of how to process<ptr>,
>> then  how do we distinguish between the case of a musical
>> notation present in the source text (in a format which we can't
>> put in TEI, and so needs ref to an external file), and the case of
>> a hyperlink to a musical notation resource in the source file?
>> if you say, "well, you have to look at the container,<notatedMusic>,
>>which
>> cannot contain hyperlinks, so courses in the former",
>> then I will reluctantly accept it, but curse because
>> you've made my processing more complex.
>>
>> --
>> Sebastian Rahtz
>> Head of Information and Support Group, Oxford University Computing
>>Services
>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>
>> Sólo le pido a Dios
>> que el futuro no me sea indiferente
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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
>
>-- 
>Dr Gabriel BODARD
>(Research Associate in Digital Epigraphy)
>
>Department of Digital Humanities
>King's College London
>26-29 Drury Lane
>London WC2B 5RL
>
>Email: gabriel.bodard at kcl.ac.uk
>Tel: +44 (0)20 7848 1388
>Fax: +44 (0)20 7848 2980
>
>http://www.digitalclassicist.org/
>http://www.currentepigraphy.org/
>_______________________________________________
>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