Extension vs Module vs Profile

[kristojorg]

What is meant to be the functional difference between an extension, module and a profile? A profile seems to declare that a manifest uses some extension, but there doesn't seem to be a way to declare that a manifest uses a module. What is the relationship between these three concepts?

[kristojorg]

Furthermore, how does the presentation hints module square with the epub profile?

1. The epub profile allows for properties.layout in a link, which seems to conflict or at least overlap with the properties.presentation in presentation hints.
2. The epub extension schema (is this the same as the epub profile?) allows for a presentation.layout property in the manifest's metadata, which conflicts with the presentation property defined in the presentation hints module. Note: I made a PR to document this metadata property in the Epub profile docs here

[kristojorg]

I see, thank you. In my opinion, the modules distinction is a bit unnecessary or unclear. For example, I'm not sure why the duration or bitrate properties would be an optional link property while encryption is a separate module. In this case the encryption property actually seems to be more generic. Any resource could be encrypted while only audiobook resources could have a duration.

My personal recommendation would be to do away with the module concept as a whole and simply have the link properties contain any optional properties that are profile-agnostic and any profile-specific properties be included in the profile (divina presentation hints for example)

[kristojorg]

That being said, I'm obviously missing a lot of context and y'all seem to have good reasons for things in my experience : ). Just wanted to toss in my 2 cents in case it's useful

[mickael-menu]

And we might do just that when Encryption is the only module left. Although I can see why functionally Encryption is not a core property and we might want to keep it separate.

Moving duration and bitrate to the Audiobook and Divina profiles could be a solution too. I found these properties a bit weird in the core spec.

Thank you, an external look is always useful.

[HadrienGardeur]

I don't think that moving duration or bitrate to the Audiobook or Divina profiles would be a good idea.

They both apply to any audio or video resource, which is generic enough to warrant a presence as a core member of the Link Object. The same can be said about height and width which both apply to any image or video resource.

[kristojorg]

I think that's fine @HadrienGardeur , but would recommend either clarifying what a "module" is, or simply doing away with the concept altogether. It seem the Link Object could have duration, bitrate, height, width and encryption all as optional properties. I'm not entirely sure what makes encryption a "module" here while the others are currently optional properties. Personally, I would do away with the concept of modules altogether and leave just optional properties and profiles.