Should the manifest be optional in the package? #34
Comments
|
OCF lite should not take that decision on behalf of the author. Instead it should simply define the two well-known locations ( Each profile can then state a preference between entry page and manifest, if necessary. I would expect the following preferences per profile:
|
|
I would advocate for making the manifest required (and the PEP optional). A well-defined manifest would serve a multitude of purposes, at every step of asset processing. |
|
@geoffjukes the manifest is required. That is at the basis of WPUB and that is not put in question. Furthermore, in WPUB, there are two ways to provide the manifest:
In both cases the PEP as well as the manifest is required for a WP. The current issue is on whether option no. 2 would be allowed or not for a package, and issue #33 is whether, in the case of a separate manifest file, the PEP should become optional in a package |
|
@iherman again I think my confusion of the goals of pwpub and wpub are coming into play here. I had (possibly wrongly) assumed that pwpub was about agreeing a standard for the packaging of wpub's. But some of the conversations and responses in pwpub seem to imply there is a split between the two. That would be highlighted by wpub requiring a PEP, and it possibly being optional in a pwpub. If I'm right, surely the optional/required debate is better suited to the wpub project (and if it is, I apologise for not seeing it). I'm very late to the party here, and there is an over-abundance of dialog for how I process information. |
|
@geoffjukes is making a great point. This repo should be discussing Packaging only. |
I do not think so. in WPUB we have already decided and accepted that the PEP is required when a WPUB is on the Web. When the discussion on packaged came up, many asked to drop this requirement for the packaged version of a WPUB. That is where the controversy is, ie, it is, as far as I can see, part of the packaging discussion and this discussion only... |
|
@iherman So a PEP is required in WPUB depending on where/how it is deployed? That seems strange to me. |
|
I think I'd be okay with the PEP required for WPUB, and optional (at least for the audiobooks "profile") when packaged. |
|
This issue was discussed in a meeting.
View the transcriptPEP in a packageWendy Reid: #33 Wendy Reid: First topic today is final topic from last week: issue 33 from the Packaged Web Publication repo, about primary entry page becoming optional… … a quick recap, and clearing up some questions. The main proposal right now is Ivan’s… … PWPs may give you the option to make index.html or a JSON manifest the primary entry page… … an alternate proposal was brought up on GitHub, the so-called ‘minimal’ PWP. The index.html only exists to point to the manifest … this is specific to PWPs – just for the package context, not for web publications as a whole. Does anyone have comments? Ivan Herman: Matt came with a proposal which I personally consider complimentary to the previous proposal, but some people might disagree … but I would prefer Matt to make the proposal Matt Garrish: In the discussion around primary entry pages and whether it’s required, we may be overlapping too much with audiobooks and web publications, expecting audiobooks to always be web publications… … what I proposed was separating the manifest so the primary entry page doesn’t always have to be present with a packaged audiobook/epub… but it can be … if the publisher wants it to be a conformant PWP, the publisher can include the entry page … Ivan posted a better clarification of this morning this morning, which is that the packaged formats are somewhat separate from a WP… the package format doesn’t always have to be a WP … everything becomes compatible. In its packaged form, the audiobook can be valid. It’s essentially making everything more abstract… … getting out of the mess of how something remains logically consistent, even if these other formats don’t want all these other WP requirements to be present Wendy Reid: #33 (comment) Ivan Herman: I want to re-emphasize: everything that Matt said is obviously true, but one important thing is missing: a reading system MUST be able to understand the packaged version of full web publications… … must be able to understand the primary entry, find the manifest out of that, so that a WP in the traditional sense, by just zipping it, even if I called the manifest file something else (although the index file must be kept) it’s still valid Laurent Le Meur: I totally agree with Matt’s point. This is conceptual. Nevertheless, when we describe the spec, it will be very complex to express that conceptual model and at the same time to explain what Ivan said: a reading system must be able to understand everything with a primary entry page … I propose we follow what Ivan suggested before: stating the primary page OR the manifest: one or the other… Ivan Herman: +1 to laurent_ Laurent Le Meur: which for processing is easy to understand. It doesn’t mean we don’t have to explain this model, but I’d be careful not to make the concept too complex… Wendy Reid: We’re back to the original proposal. The resolution would be: a PWP may include either the primary entry page or manifest but must contain one of those two Ivan Herman: I think the proposal has two equally important parts. Wendy Reid: So there are two resolutions Proposed resolution: Restructure the document to reflect the publication structure as primary, with web publications and packaged web publications as modules (Wendy Reid) Ivan Herman: -> Matt’s description for the proposal: #33 (comment) dkaplan31: +1 Tzviya Siegman: +1 Ivan Herman: +1 Geoff Jukes: +1 Joshua Pyle: +1 Rachel Comerford: +1 Ric Wright: +1 Franco Alvarado: +1 Mateus Teixeira: +1 Simon Collinson: +1 Ben Schroeter: +1 Luc Audrain: +1 Bill Kasdorf: +1 Gregorio Pellegrino: +1 Wendy Reid: Resolution accepted Resolution #2: Restructure the document to reflect the publication structure as primary, with web publications and packaged web publications as modules {: #resolution2 .resolution} Proposed resolution: WP keeps PEP as a requirement, PWP will give the option of using the PEP or the Manifest, but one must be present in the package (Wendy Reid) Ivan Herman: -> Ivan’s consensus proposal: #33 (comment) dkaplan31: -1 Laurent Le Meur: +1 Ivan Herman: +1 Garth Conboy: How does this fit in with what Laurent just said about or/both? Wendy Reid: OR/BOTH would work here, but at least one has to be present Deborah Kaplan: I’m -1 unless it becomes EXACTLY one must be present … one, but only one, must be present… … from my experience of working with small producers, people will be confused, which means publications will be wrong, which means reading systems will behave inconsistently… … creators will have to come up with workaround due to inconsistent implementation… … the option of having two will end up with badness. Ivan Herman: The resolution which I proposed said that the processor MUST look for a primary entry page and if it finds it, MUST process according to the rules. If it doesn’t find it, it looks for a manifest Deborah Kaplan: As long as it’s 100% clear to creators and reading systems what will happen, that’s fine Laurent Le Meur: I was very clear about that dkaplan31: in that case I am changing my vote to a +0 from a -1 Wendy Reid: Would it be better to rephrase the resolution as either or but at least one must be present? George Kerscher: As someone producing a publication, I’m going to start with my manifest. For an audiobook, I zip that up and distribute it to various places and they process it… … if I want to add a primary entry page then I could serve it up on the web and all is well. To my mind, I’m progressively enhancing the publication Ivan Herman: That workflow is correct Matt Garrish: My question is one of consequences. When we require specific names, it’s going to mean that if you unpackage it on the web, you can only do this with one WP in a directory due to collisions … are we putting a limitation that we got away from earlier back into play – that you can’t have multiple articles in one directory? Deborah Kaplan: +0 and not +1 because I still dislike giving people choices, because small creators are confused by choices, while meanwhile large publishers can create a PEP trivially as part of production workflow whether they need one or not. But not -1 as long as clear flow is documented. Ivan Herman: Matt is right. If we don’t have a name restriction, we have to do something to the package itself to find where to start. This is zip, we aren’t having web packaging, so I’m not sure what else we can do Matt Garrish: It’s a circular problem: if we don’t have specific names, how do you find what you’re looking for - if you have something else finding the names, how do you prevent those from colliding?… … trying to prevent the index.html problem from re-occuring, but I’m not sure how much of an issue it is… Tzviya Siegman: This makes me uncomfortable too – it’s something we’ve always tried to avoid doing. In the world of scholarly publishing, if I have a journal of 30 articles, each published on their own, each will have this problem… … I feel like this is going to come back to bite us… Benjamin Young: My question was similar: if we have specified names for these things and a tree of inheritance where down a certain road you have index.html and down another road you don’t… … is it possible to make a web audiobook in that world, or do they no longer intermingle?… Charles LaPierre: Thinking about a journal made up of multiple article, wouldn’t each article be its own subdirectory, hence no collisions? Ivan Herman: This whole filing thing reflects that what we’re using is a packaging format that isn’t Web friendly. And we know that, which is why we consider the current format as a lightweight temporary solution… … I’d be happy if we had today a format which allowed me to refer to a URL for every file, and maybe we’ll have one before I retire. But we’ve agreed to define a lightweight packaging format now, and we have to live with it… we don’t really have a choice … we could require a specific way of zipping which puts the file first in the zip file, which makes the publication more complicated, because I can’t just take a directory and zip it… this isn’t the solution… Wendy Reid: We have to find a compromise Ivan Herman: We have to accept the deficiencies of the system right now Garth Conboy: I agree with Ivan. We dislike the alternatives more – anything that makes it harder is a no-no… … there’s a manifest.json and index.html which are both magic names… … the actual manifest can be standalone or included in the PEP… … what are the changes that we propose to ensure there is no possible duplication? Ivan Herman: What I’ve proposed: the first step the reading system does is locate the PEP. If it finds that, then it follows the processing steps that are described in the WPUB document… … at first look at your own file, otherwise look for a Manifest file and that’s your manifest… Matt Garrish: We’re making our WP format dependent on the packaging… I can live with this, but what if a better packaging format comes along in future?… … would we drop these restrictions? Ivan Herman: If we find a packaging format that allowed that, then yes Laurent Le Meur: In future, this packaging will be used by publishers as a booster for leaving earth. When the publication is exposed on the Web, pure web packaging becomes important then Benjamin Young: A general question: are we open to analyzing other formats for web archiving and distribution, the primary component being that they keep URLs around, or continue with zip? Wendy Reid: If you recall a few weeks ago, we did open up the request for analysis of the different potential formats. They were analyzed based on the pros and cons of that table. If we missed anything in that table, it’s good to know about… … we made the decision based on the ≈7 formats we looked at in that table Ivan Herman: Let’s not reopen closed issues. For now we’ve decided to go with what we have, knowing that eventually the committee will produce a webby packaging format … we explicitly said that if and when that happens, then this working group or its successor will look at it and consider it… … but we need something today if we want to produce anything before the end of the life of the working group, less than 18 months from now Proposed resolution: WP keeps PEP as a requirement, PWP will give the option of using the PEP or the Manifest (with rules agreed to resolve any possible duplication [start with looking for PEP, and process that first; if not present look for standalone manifest]), but one must be present in the package. (Garth Conboy) Ivan Herman: we decided on something and shouldn’t reopen today Bill Kasdorf: Quick question: if we’re seeing that not all packaged audiobooks are web publications, then we shouldn’t call them packaged web publications, right? Laurent Le Meur: in fact we don’t. Bill Kasdorf: Then they aren’t really PWPs, then Proposed resolution: (Less typos version) WP keeps PEP as a requirement, Lightweight Packaging will give the option of using the PEP or the Manifest (with rules agreed to resolve any possible duplication [start with looking for PEP, and process that first; if not present, look for standalone manifest]), but one must be present in the package. (Garth Conboy) Ivan Herman: +1 Garth Conboy: +1 Charles LaPierre: +1 Tzviya Siegman: +1 Matt Garrish: +1 Laurent Le Meur: +1 Rachel Comerford: +1 Ben Schroeter: +1 Joshua Pyle: +1 Bill Kasdorf: +1 Tim Cole: +1 Geoff Jukes: +1 Luc Audrain: +1 George Kerscher: +1 Mateus Teixeira: +1 Gregorio Pellegrino: +1 Resolution #3: WP keeps PEP as a requirement, Lightweight Packaging will give the option of using the PEP or the Manifest (with rules agreed to resolve any possible duplication [start with looking for PEP, and process that first; if not present, look for standalone manifest]), but one must be present in the package. {: #resolution3 .resolution} Wendy Reid: We’ve made a decision, with 20min to spare… moving on to our next issue… Ivan Herman: I propose that we merge the two requests from Laurent whenever he feels comfortable… … reading that document via the pull request is a pain, and it’s better if we merge it in Laurent Le Meur: I prepared the merge last week. We can work from that Wendy Reid: If no opposition, we’ll merge as soon as Laurent is ready Resolution #4: Laurent will merge the pull request as soon as he can {: #resolution4 .resolution} |
|
Per resolution above, and merged PR #30, closing this issue. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In the current proposal #30, the manifest file is required.
It has been argued in #30 (comment) that "This appears to disallow embedded manifests, and thus restricts what types of web publications can be packaged."
in #30 (comment) I put forward that "We may consider that the container contains a canonical representation of the WP, where the manifest is external..."
Hoping we can solve this issue here.
The text was updated successfully, but these errors were encountered: