blackstoneaudio / audiobook-spec

Simplified Audiobook Specification for App development
2 stars 0 forks source link

naming #1

Open dauwhe opened 5 years ago

dauwhe commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

geoffjukes commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

@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.