Can the links/manifest model be simplified?

[dauwhe]

In the proposal, a rendition object (see issue #13 ) contains a links array which contains objects describing the files, unless they are not spine items, in which case they're one level deeper in a manifest object. Might a simpler structure contain the same information?

{
    "metadata": {
        "title": "hello, world"
    },

    "manifest": [{
        "href": "index.html"
    }, {
        "href": "style.css"
    }]

}

One could determine which files are spine items by file extension and/or attribute. Again, in the common cases HTML files are spine items, and everything else isn't.

Advantages:

1. Simplicity of authoring and structure
2. Can easily handle current EPUB 3.0.1 linear=no behavior

Disadvantages:

1. Processing required to extract "spine"
2. Depending on details, it may be more work to create image-only publications
3. Imposes an ordering on non-spine files

[HadrienGardeur]

There are two separate issues here, could you divide things a little differently?

First one is that you don't want to use "links".
Second one is that you don't want to separate the spine from the manifest.

[HadrienGardeur]

I'd like to propose a solution for that, which would be compatible with your proposed example:

• collections are always the same thing: identified by a role and they can contain metadata, links and other collections
• in our proposed JSON syntax, we would also allow the use of link objects when a collection has no metadata and no sub-collection

Basically, this would avoid defining manifest differently (it's still a collection), and would also extend to any other collection whenever it's useful.

A full collection uses:

• metadata
• links
• sub-collections

While a compact collection is limited to link objects.

While it does make authoring easier, it'll make parsing those files a little more complex (since you'll have to detect if you have a full collection or a compact collection) but it's probably an acceptable compromise.

[HadrienGardeur]

My proposal would still separate the spine from the manifest btw, but it makes the syntax more compact and closer from what you're proposing.