[tei-council] <notatedMusic> changes required

Martin Mueller martinmueller at northwestern.edu
Sat Jul 9 15:11:52 EDT 2011

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

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?)
>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
>> 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>,
>> 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
>> 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
>tei-council mailing list
>tei-council at lists.village.Virginia.EDU
>PLEASE NOTE: postings to this list are publicly archived

More information about the tei-council mailing list