How to include MusicXML

[josteinaj]

We are looking into the possibility of including MusicXML as part of our single-source production workflow, which is centered around EPUB 3. The only output (at least initially) will be paper braille, so we won't distribute the EPUB itself. We'll only use it during production. I assume there's no EPUB reading system that handles MusicXML anyway.

So, I was wondering what would be the most appropriate way to include MusicXML in an EPUB. My suggestion is to do it as similar as possible to how MathML is included.

I guess I don't expect MusicXML to be included in the EPUB standard in the foreseable future, but being able to include XML from other namespaces in a EPUB publication for use in a single-source publishing workflow is something that would be useful.

• In the package document:
  • properties="musicxml" on XHTML documents that contain MusicXML
  • media-type="application/vnd.recordare.musicxml+xml" on MusicXML files
  • allow MusicXML files to be referenced directly from the spine
• In content documents:
  • allow the MusicXML root elements <score-partwise> and <score-timewise> in any context where a XHTML <p> element can occur. No other MusicXML element may be the child of an XHTML element.
  • probably put the MusicXML elements in a namespace other than the default namespace: Namespace for MusicXML musicxml#266

Would this be appropriate? I suppose it won't validate with epubcheck, so I'd have to filter out some epubcheck errors.

[llemeurfr]

allow MusicXML files to be referenced directly from the spine
a pure MusicXML structure can be considered as a foreign resource, you can include it in the spine IF you provide a fallback EPUB Content Document.

But elsewhere you seem to state that MusicXML structures would be embedded in XHTML structures. If this is the case, MusicXML files would never be referenced directly from the spine.
Or am I missing something?

[mattgarrish]

Inlining foreign namspaced content is essentially what epub:switch was designed for. The idea was that you could include mathml, chemml, musicxml, etc. anywhere and also have a fallback to HTML. It's kind of fallen out of favour (as in deprecated now), as the days of EPUB inventing solutions have passed, but there's no reason you can't continue to take advantage of it. If you're filtering out content for distribution, the switches and lack of support for them may never come into play.

If you actually want to reference musicxml files from spine itemref elements, all you need is a single fallback document they all reference to shut epubcheck up - it could just have a simple message that musicxml isn't supported if someone does try to open these books in an epub reading system.

[mattgarrish]

Forgot the properties part, but you can always use your own prefix:

<package ... epub:prefix="foo: http://example.com">
...
   <item ... properties="foo:musicxml"/>

[josteinaj]

@llemeurfr / @mattgarrish re: fallback document: right. I'll add a fallback for standalone documents then.

@llemeurfr I was thinking of allowing both standalone MusicXML files, as well as inline MusicXML. If a publication primarily consists of musical notes, then it might make most sense to just put a MusicXML document in the spine. If the musical notes are interleaved with paragraphs, lists, tables etc., then it would make sense to put it inline.

@mattgarrish Aha, I had forgotten about the epub:switch element (seeing as it's deprecated and all). I'll use that then.

properties prefix: ok, I'll come up with some prefix and namespace then.

Many thanks to you both!

[dauwhe]

@josteinaj Have we addressed your concern to your satisfaction? OK to close this issue?

[josteinaj]

Hi @dauwhe. Yes, as long as the epub:switch element remains valid, I'll be able to include MusicXML in our systems.