>
> > Many on the industry side of this group think that Web Packaging will bring nothing to publications that are not "born on the Web"
>
> Could you expand on "Web Packaging will bring nothing to publications that are not 'born on the Web'"?
>
Knowing that most ebooks currently usually follow a workflow like:
Word (author) -> XML+images+metadata in a CMS (publisher) -> EPUB (B2B interchange btw publisher and distributor) -> EPUB/KF8/etc. (bookseller).
or
Word or more visual authoring tool (author) -> InDesign (publisher) -> EPUB FXL (B2B interchange btw publisher and distributor) -> ...
and audiobooks should use a workflow like:
audio oriented authoring tool (author) -> mp3 or aac or Opus + metadata in a CMS (publisher) -> packaged audiopub (B2B interchange btw publisher and distributor) -> packaged audiopub (bookseller)
it appears that all resources which are part of a publication (ebook or audiopub) are during editing in the hands of the publisher and packaged together.
If this package is open by a reading system, they are all more or less handled as local files.
If the publication is unpackaged and exposed on an http server, all resources are in practice in the same domain and fetched using simple GET.
A 'born on the web' publication can be much more complex, because its resources may be split all over the Web and other http verbs may be required to access them. In this case, using a full fledged Web Packaging makes sense when one wants to freeze the publication as a file.
Laurent