-
Notifications
You must be signed in to change notification settings - Fork 48
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
Elements and APIs in the charter scope #79
Comments
Maybe we need to take time to confirm which APIs we want to design, based on the API comparison we made in the white paper. But it will cost a lot of time... |
Committed 6dde39a per yesterday's call. |
I see that the CG discussed this and resolved to leave the scope open-ended. I thought I would document reasons why I personally believe that this is problematic. Looking at the minutes, I see "I think we should narrow down the APIs in the Deliverables part, but not in the Scope part". I believe that should be the other way round: in practice, legal teams review the Scope part more carefully than the Deliverables part because the Scope section is the one that is going to allow/disable work on specific deliverables within the Working Group. Said differently, the Scope determines the scope of patent commitments, not the list of deliverables. My reading of the current draft charter is that it would allow the working group to start work on APIs such as: a Map API, a Contacts API, a native filesystem API, a GPU API, a Machine Learning API, a Bluetooth API, a WebTransport API, etc. "that would enhance the interoperability among different MiniApp platforms". Basically any Web technology seems potentially in scope of the group, including developing another HTML spec for MiniApp. This is problematic, not because it would necessarily be a bad idea to develop such standards, but because:
I would do the opposite: restrict the scope section to the core specifications, use the MiniApps CG to incubate new features, and re-charter when some incubated document seems ready to move to standardization. Just my two cents! :) |
+1. I'm reopening the issue to make sure this gets seen, and I'm flagging it as "needs-resolution". |
For the 2nd bullet of the scope, how about: |
"Component" is not defined well enough in the charter. (And perhaps that should be a more general comment.). Specifically: I don't understand what the term means in this context. Explain (in the charter, or by reference within the charter)? |
Discussions in yesterday's call: https://www.w3.org/2020/07/09-miniapp-minutes.html#t03 |
I think "components" means encapsulated reusable code for rendering a part of the UI. See some examples in: https://open-ui.org/ |
Yes. Components are mostly UI-oriented (e.g. a text box, a list view), while sometimes may be background-service without a UI (e.g. a timer, or background audio). In the current scope, UI components are first proposed since the scope is relatively clear. By specifying the components, one can expect the standardized way of configuration and interaction with the MiniApp pages (which are H5-alike but not the same). p.s. MiniApp pages requires more UI components than what normal H5 tags can provide, such as list, swiper and tabs that provide common experience of a native mobile app. |
Just submitted #118 based on comment in #79 (comment) |
Discussions in yesterday's call: https://www.w3.org/2020/10/15-miniapp-minutes.html#t05 |
Fixed in #135 per discussions in the last CG meeting. |
https://w3c.github.io/miniapp/charters/wg-2020.html
It has been pointed out that the scope is too open-ended and is similar to the scope in the old SysApps WG, and we should clarify more narrowly to help with member acceptance.
(This issue comes from a W3C Strategy Team discussion.)
The text was updated successfully, but these errors were encountered: