Meeting minutes
Status review of existing deliverables (against FPWD/CR plan)
Manifest
angel: any progress on the MiniApp Manifest? It was published as FPWD
Yongjing_Zhang: for manifest
… I think there's still the i18n issue
… Huawei will propose some content for i18n
… Zitao is working on that
angel: timeline?
Yongjing_Zhang: ideally we would like to address the issue by the end of next month
zitao: for i18n
… per previous discussions we should align with WAM
… they have some candidate solutions
… we should double check and harmonize with them
angel: anything else?
zitao: we have done some homework
zitao: looked at issues in CG
… about TV and IoT
<angel> https://
zitao: we should see whether we need to add members for them
… I'd like to prepare some PRs and discuss with you all
angel: do you think we can start review the PRs in the next meeting?
<martin> Current discussion of i18n in the Web Application manifest WG: https://
zitao: yes
Lifecycle
QingAn: I sent a PR
<angel> https://
QingAn: you can open the preview link
[QingAn goes through the PR]
QingAn: I added Web IDL
QingAn: made the spec more readable
QingAn: hope to get feedback and consensus for publishing FPWD
angel: let's hear if there's any comment or question from people on the call
[silence]
angel: maybe people need some time to digest
… any objection on merging the PR?
[silence]
angel: then we will merge this PR, and send a two-week CfC for publishing FPWD
… any comments or questions on lifecycle?
… let's move to Packaging
Packaging
<angel> https://
Yongjing_Zhang: two PRs
… refinement about the media types section in annex
[Yongjing_Zhang goes through the major changes]
Yongjing_Zhang: magic number is the same as ZIP
angel: not sure about the wording
… "intend to"
Yongjing_Zhang: will remove it eventually, as the spec moves forward
angel: any other comments about this PR?
[silence]
<angel> https://
angel: security and signature
[Yongjing_Zhang goes through the diff page]
Yongjing_Zhang: I made some editorial changes
Yongjing_Zhang: not technical
Yongjing_Zhang: moved a figure to Annex B
martin: The figure was in section 6 (Security), it's better in the annex.
Yongjing_Zhang: add a note about sub-packages
Yongjing_Zhang: need more work
angel: do you think you need more time or we can merge it now?
Yongjing_Zhang: I think we can merge it now
… there were some reviews
… seems OK
… not technical change
… just for readibility
angel: any objections on merging this PR?
[silence]
Manifest
<angel> https://
angel: we discussed this in the CG
xfq: this is different from the CG issue
xfq: the CG issue is about API, and this issue is about manifest member
angel: this is an old issue
xfq: It is not clear to me if this is just a default orientation when the user opens a MiniApp (the user can change it when using the MiniApp)
xfq: or a locked orientation (the user can't change it)
xfq: we should align with Web App Manifest
Yongjing_Zhang: agreed
QingAn: also agree we should align with web app manifest
angel: any other comments?
[silence]
Resolution: let's make it align with Web App Manifest, and close this issue
<angel> https://
angel: another issue, opened ~1 month ago, about sub-package
xfq: wonder if we should specify this in the Manifest spec and the Packaging spec
xfq: we need to hear MiniApp vendors' opinions
Yongjing_Zhang: yes, this is a useful feature, we should specify it
… in my previous PR, we should discuss it in the current stage
… in the packaging spec, need a section for sub-package
xfq: yep, also in the Manifest spec
Yongjing_Zhang: yes, need some work
… maybe not be easy
xfq: L1 feature? or defer it?
Yongjing_Zhang: depends on the willingness of the group
Yongjing_Zhang: if there's no interest we can solve other issues first, like the i18n issue
Yongjing_Zhang: the page layout / template issue is also more important
QingAn: very interesting topic
… we need to look into the scope of this issue, it could be bigger than what's described in the issue
… a miniapp page or some a part of the page is not necessarily rendered locally
… it may also be rendered in the cloud and then downloaded to the local device
… whether it has an independent render
… which part of the mini app page can be rendered first
… extending the Manifest spec may not be enough
… we can do some work in the Packaging spec
… let's keep the discussion open
xfq: yes, this is a more advanced feature
angel: shall we have an extra meeting for this? or GitHub discussion first
QingAn: let's discuss in the GitHub issue first
QingAn: if we have consensus on the direction we can make a PR
… make it an issue for both Manifest and Packaging
Yongjing_Zhang: sure, we will be happy to work on this
QingAn: I volunteer to do some work on this
angel: thank you
Addressing
Dan_Zhou: We are still discussing internally
Dan_Zhou: we plan to submit a PR before the next CG meeting
Widget
angel: any update?
[silence]
White Paper
xiaoqian: saw some issues about the MiniApp Standardization White Paper
… the white paper was published by the Chinese Web Interest Group
… I wonder the MiniApps WG would like to work on it
angel: it makes sense to transfer the white paper to the CG
xiaoqian: we can't publish /TR in the CG
angel: but it's not in the WG charter
xfq: I think the WG can publish non-normative documents
angel: any objections on taking it from the Chinese IG?
[silence]
angel: let's try to review it next time
angel: to see if we can come up with a plan on updating the white paper
Packaging
martin: re Packaging
… per WG charter we should publish it as FPWD in Q2 2021
… time is tight
… we need to decide the file/directory structure
… this is really important
… style, template
… it's something we need to define
… need to decide as soon as possible
… what CSS modules we support
… XML template, data binding, event handling
https://
martin: related to UI comoponents
… we need to define how to define components first
… we can continue to discuss in GitHub
angel: thank you, martin
Publication process
xfq: since some people are new to W3C working groups, let me briefly introduce the W3C process
xfq: in the W3C Process, a Recommendation-track document passes through three levels of stability
xfq: Working Draft (WD) is the design phase of a W3C spec
xfq: the first official Working Draft is called the “First Public Working Draft” (FPWD)
xfq: publishing FPWD usually means that the Working Group as a whole has agreed to work on the spec
xfq: the second phase, Candidate Recommendation (CR) is the testing phase of a W3C spec
xfq: this phase is about using tests and implementations to test whether the spec is implemented
xfq: the transition to the next stage is “Proposed Recommendation” (PR)
xfq: during this phase the W3C Members need to approve the transition to REC
xfq: Recommendation is the completed state
xfq: regarding the publication of working drafts, there are two points I would like to discuss with the group.
xfq: first, we can use echidna to publish specs
xfq: by "publish" I mean publishing to the W3C website
https://
xfq: I recommend using echidna, because almost all groups are using it
xfq: it can greatly reduce the time required to prepare publishing the spec
xfq: second, we can use GitHub Actions to build/validate/publish the working drafts for every commit, it depends on whether we need it
xfq: ^ FYI - some links to other groups' decision
xfq: can we publish with echidna? also can we use GitHub action to publish WDs?
Yongjing_Zhang: Will this change our editing process?
xfq: no
xfq: if we use echidna, we don't need to send an email to webreq@w3.org for publication
angel: I'd like to suggest we explore both option
AOB
<xiaoqian> Next meeting: 24 June, same time
[adjourned]
<martin> Thanks! Undertood, I used it locally before
<martin> I agree it's better using that tool