Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify relationship with WICG/IETF’s Web Package Format (WPK) #120

Closed
js-choi opened this issue Jan 9, 2018 · 4 comments
Closed

Clarify relationship with WICG/IETF’s Web Package Format (WPK) #120

js-choi opened this issue Jan 9, 2018 · 4 comments

Comments

@js-choi
Copy link

js-choi commented Jan 9, 2018

The Publishing WG’s Packaged Web Publications (WPub/PWP) and the WICG’s and IETF’s Web Packaging Format (WPK) are quite similar and overlap in many use cases. The relationship between the two standards, however, is unclear to the reader of both specifications.

The WPub/PWP specification does not mention WPK. In its GitHub issues, the only references I could find were #5 (comment) and #5 (comment) by @HadrienGardeur, which does not definitively answer this question. (Possibly pertinent issues also include #10, #90, and #111.)

I similarly found only slim references to the Publishing WG in WPK’s repository. Web Packaging Format’s use-cases note has a “Packaged Web Publications” in its “Nice-to-have” section; it refers to the Publishing WG and discusses several abstract use cases provided by the WG, without actual reference to WPub as a specification. Several WPK GitHub issues (WICG/webpackage#3 “Relationship to DPUB”, WICG/webpackage#32 “Document Adobe’s use cases”, WICG/webpackage#37 “Add a list of goals and non-goals”, WICG/webpackage#71 “Start an internet-draft”) also refer to the Publishing WG. Some Publishing WG members (@lrosenthol, @iherman, @dauwhe) have participated in these issues.

None of these references talk about WPub/PWP as a separate specification, and none of them elaborate on its relationship with WPK. Neither the WPK specification itself nor the obsolete TAG Packaging on the Web draft make any mention of WPub either.

This is triply confusing. There is clear overlap between the two specifications’ use cases: for instance, both initiatives appear to desire addressing Google AMP’s use cases, and even their names are confusingly similar (WPK vs. PWP). Both are being actively developed—there were even announcements regarding both on this same week (the WPub public-draft announcement and the Google AMP Project’s announcement on its transition to WPK). And some of the same people have participated in both discussions on one standard and discussions on the other; there has clearly been some collaboration but of uncertain nature.

For readers of both specifications, it would be useful if their authors clarified this uncertainty. “What is the relationship between the two standards?” “Why are there two separate standards?” “How are their use cases and file formats similar and different?” Further active collaboration between the two specs’ authors might also be worth pursuing. Though it might be too late for unification, it would be a shame if there was fragmentation of the same goal into two formats. Browser vendors are probably less likely to implement two formats than just one. On the other hand, if their use cases are irreconcilable, then that should be made explicit in the specifications.

(I had previously posted this issue in WICG/webpackage#103 but realized that it may be more appropriate to raise it here in w3c/wpub.)

@lrosenthol
Copy link

The PWP specification, purposefully, does not specifically call out a particular packaging format. Instead it is focused on the issues involved with taking a Web Publication and putting it into a container/package of some fashion.
The reason that it does not call out a particular packaging model is that we are aware of at least three potential use cases (or profiles, if you will), each of which desires to align with the PWP specification but wants to use a different packaging format. To this end, we want are trying to build a framework that enables such things - and then call out in the particular profiles the specifics. One of those profiles would most certainly use the WPK technology and so in that document we would address the specific details.

@TzviyaSiegman
Copy link
Contributor

Per w3c/pwpub#11, WPub is considering WPK for a packaging format. We refer to the WICG issue. Apologies if that is not clear. We have been in regular contact with @jyasskin about the progress of Web Packaging. At this point, we have not chosen a packaging format, but we do intend to select a format for PWP. (@lrosenthol - let's touch base to make sure we're on the same page.) We welcome feedback and discussion with those involved in WPK. If you have information on its progress and acceptance, please provide details. Thanks.

@jyasskin
Copy link
Member

jyasskin commented Jan 9, 2018

@js-choi Note that https://www.w3.org/TR/2018/WD-pwpub-20180104/#packaging does mention Web Packaging as one of the options.

@js-choi
Copy link
Author

js-choi commented Jan 10, 2018

Excellent, thank you. It was my fault that I had missed searching the w3c/pwpub repository, rather than just w3c/wpub and wicg/webpackage. Looks like there has been discussion about this at w3c/pwpub#17 as well; I simply had been looking in the wrong places.

A key decision on this specification will be the choice of packaging mechanism (section 5). The working group has decided to evaluate Web Packaging (see the Web Packaging Format Explainer) and to wait for its maturation before proceeding. This has been a major cause of the publication of this specification as a First Public Working Draft in such skeletal form.

I don't know how I missed this note from the PWPub specification; I must have focused too much on WPK's and WPub's specifications. It completely addresses my issue. Thanks, everyone, for your explanations.

@js-choi js-choi closed this as completed Jan 10, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants