On Tue, 2012-12-18 at 09:48 +0000, Sebastian Rahtz wrote:
> Some of this has come up before, and there has been a worry that really defining a <media> element well would end up duplicating
> what HTML has, and so people should just embed raw HTML(5) in their TEI in its own namespace, same way as we do
> SVG or MathML.
> so just some caution about the tempting view of "<media>, how hard it be can, eh"

What alternatives are being considered? If the idea is still to go back
to <binaryObject>, then here are more reasons against it, besides those
already mentioned by Syd and Martin:

1. It would be better to have other types of embedded binaries be
handled in way parallel to images (use <graphic> and link to the file)
rather than require a substantially different mechanism.

2. teitohtml and teitoepub currently convert <binaryObject> to something

<img src="data:;base64,..."/>

The following page is out of date but I doubt that the limitations on
the size of src have *completely* evaporated:

In brief, having an src attribute that contains megabytes of data is
asking for trouble because browsers have hard limits. (Are epub readers
better?) Now, there is nothing which *forces* teitohtml and teitoepub to
use the "data:" scheme. They could conceivably detect that a
binaryObject is so long that it is risky to use the "data:" scheme,
convert it back from base64 to binary file and link to the binary file,
but why the awkward trip through base64 in the first place?

3. Requiring that a binary file be converted to base64 complicates
converting from TEI to whatever target format. Any time the original
audio file is changed, a new base64 conversion must be made before
something like teitoepub (or equivalent) is invoked. It is an additional
step, one which can be completely eliminated by allowing embedding all
media types in the same way we already do when we want to embed an

Out of curiosity I've tried to see whether I could break how the teitoX
tools handle <binaryObject>. I was able to. Bug reports to follow soon.