naming

[dauwhe]

This is great!

I'm scrambling right now to find some way to harmonize this, the existing work on web publications, web app manifest, and EPUB. How attached are you to the particular names of items in your format? It might be possible to obtain some consistency across a wide range of publication types and uses. I'll keep you posted.

Kind regards,

Dave Cramer
EPUB 3 CG, Publishing WG, CSS WG

[geoffjukes]

Hi @dauwhe

I'm not attached to any specific naming, as long as the name makes sense. For example length and runtime mean the same thing to me.

I would be happy to adjust to a standard/consistent nomenclature, and by extension participate in any discussion on same.

Geoff

[dauwhe]

As an experiment, I've written up a rough proposal for a data model that would cover lots of different publishing use cases. The audio section is quite influenced by your work :)

https://github.com/dauwhe/pdm/

[geoffjukes]

@dauwhe Excellent - thanks! I'll provide feedback there

[geoffjukes]

@dauwhe I'll refactor my spec to reflect your naming. Interestingly, I originally had the audio in the playlist, much as you have it. But I found that more complex playlists led to visual confusioin.

One of my design goals (and the reason for preferring YAML over JSON) is that I want to make it as easy as possible for a home narrator to write a spec.

[dauwhe]

It's probably too early for anyone to rename anything. Just wanted to show you what I've been thinking about.

Would love to hear more about complex playlists!

[geoffjukes]

@dauwhe no worries. I'm still getting back on the horse here.

Complex playlists (such as multi-part books, boxed sets, etc) are something that we do not currently support or require. But having the playlist as a list of hashes, we can support it. There are examples in the draft.yaml that show a complex example, allowing nesting of labels etc, and a simple example.