Sorry for jumping in the conversation late. At the Music SIG meeting in Würzburg we brainstormed a bit about a generic <media> element.
Like Lou suggests, I think it makes sense to keep <graphic> in mind, perhaps by creating an overarching class that groups <graphic> and <media>.
PhD Candidate and PG Research Assistant
Department of Digital Humanities
King's College London
From: TEI (Text Encoding Initiative) public discussion list [[log in to unmask]] on behalf of Lou Burnard [[log in to unmask]]
Sent: 17 December 2012 22:26
To: [log in to unmask]
Subject: Re: some questions about non-textual components and media
Sorry, I have been offline most of today, so only just catching up with
At first, it seemed pretty self0evident that there is a strong case for
providing an <audio> element exactly analogous to the existing <graphic>
element, but with the implication that it points to an audio
representation rather than a static image.
Then I wondered whether we might not instead want something more generic
== say <media> so we could use it also to point to a video. Either way
it makes sense to give it its own specialised attributes, notably for
duration but also presumably others.
|When a binary object -- image, animation, audio, video, whatever -- is
small enough (and the encoding project warrants this), the object can be
base-64 encoded and put into a |<binaryObject>.
Like others, I think that;s largely irrelevant to this use case
> When the object's size (or just the project's asset management
> practice) precludes embedding, then an image file can be referenced in
> <graphic>. The question is what is the analog to <graphic> for audio,
> video, etc.?
> Does/Could/Should <recording> be part of the answer?
<recording> is for documenting information about how a recording was
made, not for pointing to an MP4 or whatever containing the actual