Elements and APIs in the charter scope

[xfq]

https://w3c.github.io/miniapp/charters/wg-2020.html

Elements and APIs that would enhance the interoperability among different MiniApp platforms, including UI elements, Device API, and those advanced APIs such as Account API and Map API;

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.)

[Sharonzd]

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...

[xfq]

Committed 6dde39a per yesterday's call.

[tidoust]

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:

1. Some of them are in scope of existing or proposed groups. At a minimum, the charter should indicate that the group does not intend to develop APIs that overlap with existing ones.
2. Each of them may have privacy, security, adoption implications and their standardization within W3C should be discussed and reviewed with W3C Members before they get adopted by a Working Group.
3. Various members may be unable to join the Working Group due to this, because of patent implications. At best, they won't join, which is not a very good sign. More likely, they will object to the creation of the Working Group in the first place. I may be wrong, obviously, I do not speak on anyone's behalf.

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! :)

[samuelweiler]

Each of them may have privacy, security, adoption implications and their standardization within W3C should be discussed and reviewed with W3C Members before they get adopted by a Working Group.

+1. I'm reopening the issue to make sure this gets seen, and I'm flagging it as "needs-resolution".

[zhangyongjing]

For the 2nd bullet of the scope, how about:
"MiniApp UI components, component-associated APIs, and a page layout template mechanism that would enhance the interoperability among different MiniApp platforms. Other components and APIs may be included by rechartering the WG scope as the incubation result from the MiniApp Community Group. "

[samuelweiler]

"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)?

[xfq]

Discussions in yesterday's call: https://www.w3.org/2020/07/09-miniapp-minutes.html#t03

[xfq]

"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)?

I think "components" means encapsulated reusable code for rendering a part of the UI. See some examples in: https://open-ui.org/

[zhangyongjing]

"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)?

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.

[xfq]

Just submitted #118 based on comment in #79 (comment)

[xfq]

Discussions in yesterday's call: https://www.w3.org/2020/10/15-miniapp-minutes.html#t05

[xfq]

Fixed in #135 per discussions in the last CG meeting.