Discussion of page structure file extension

[ShourenLan]

Case 1： Including multiple root nodes, the page with template reference does not fit xml specs.
Reference：
https://developers.weixin.qq.com/miniprogram/dev/reference/wxml/import.html
https://smartprogram.baidu.com/docs/develop/framework/view_quote/

[xfq]

Related discussions: https://www.w3.org/2020/03/12-miniapp-minutes.html#t05

[zhangyongjing]

If it's not intented to be an XML file, and multiple root nodes is more acceptable by the developers, we should give it a different extension name like '.maml'.
The only drawback i see right now is not being able to use .xsd for defining the formal schema.

[Ternence]

I think the miniapp implementation should follow the XML specification. And there should be a standard root node.

why we need this no root xml file? What's the benefits of this?

[zhangyongjing]

I think it's more about the developers' convension. I'm open to this, and let's see others' preferences.

[xfq]

Related: w3c/miniapp#160

[MichaelWangzitao]

I think it is a good time to pick up this thread since this may impact some standards under developing or incubating, like packaging and UI components. At the last CG meeting, we have discussed some idea about the markup language, and here are some summarizations:

How to define the MiniApp page elements and components? Ideas to reuse existing standards:

1. A MiniAppsML?

• As an XML application with a formal XML syntax and structure specified in a DTD document;
• Definition of CSS-compatible attributes for the basic elements (compatibility with CSS modules);
• In this case, MiniApps would be defined in terms of the document object model (DOM);
• Extension of the latest DOM (e.g., MiniAppElement);
• Namespace for MiniApps elements: (e.g., http://www.w3.org/2021/miniapp)

2. HTML extension?

• To implement the standard Custom Elements and polyfill them;
• Full compatibility with current HTML and DOM specs.
• Alignment with OpenUI CG to define new elements (e.g., picker, tab)

3. Variations of the MiniAppsML proposal?

• No DOM support?;
• No need for strict XML?;
• New CSS modules?;
• ...

[espinr]

Thanks, @MichaelWangzitao.

I'll complement this thread with some some additional thought on the challenges to be solved, raised in w3c/miniapp#161 (thanks @zhangking).

Templating mechanism

The existing implementations use an MVVM approach with the following main features:

• Data interpolation using {{ moustache }} notation
• One-way data-binding from
• Event handling
• Conditionals, loops for rendering

Data interpolation

The HTML spec already includes a <template> and a <slot> element, but this functionality is limited.

There have been several attempts to create template interpolation mechanisms (for instance, Apple's proposal in 2017). Currently, there is also a discussion in WHATWG), based on {{ Moustache }}-style variables in <template> elements, but no consensus yet.

Another option is using XSLT 3.0 and XPath 3.1. It would be feasible, but too complex and I think developers won't like it :)

Event handling

The standard way would be using DOM Event handlers (e.g., click (event) > onclick (handler)).

The MiniApp MVVM model to bind data and events is against the standard HTML/DOM approach:

<template>
   <div click="press">...</div>

<script>
  export default {
     press(e) {
       this.title = 'Pressed!‘
     }
  }

Conditionals, loops for rendering

As far as I know, there are no standard ways to use conditionals, loops, and similar logic in the rendering process. Any idea?

[awentzel]

<template> and <slot> are not functionally limited to my knowledge. In fact, FAST is widely using these in the standards-based Web Components that now run in all modern browsers. This team continues to adopt the latest standards and features as they come available and have an entire component library available that could be extended on if desired. This team sites on standards bodies as well as to my knowledge are the first to comprehensively deliver Web Component based solutions.

It's my opinion that we should be following the latest HTML standards including looking forward to what will be released on the horizon. I don't believe XML, XSLT, XPath would be acceptable as these technologies for the most part are now archaic and rarely used also not performant compared to alternatives. Wherever possible we should leverage all the Open UI and modern Web Standards that are in place or future features.

I also, would like to understand the desire for multiple root element support? What problems or limitations exist with the current single root structure?

[awentzel]

@zhangyongjing could you elaborate on this?

I think it's more about the developers' convension. I'm open to this, and let's see others' preferences.

I'm curious what type of developers we're speaking about? Native mobile developers? Web developers? etc?

[zhangyongjing]

I was talking about mini-program/ mini-app/ quick-app developers working with 'Wechat mini-program', 'Baidu smart-programe', 'Alipay miniapps', 'Quick Apps' etc. Those frameworks are the technical bases (or pre-standard implementations) of W3C MiniApps. Some of them are defining their own markup languages (WXML, SWAN, AXML) for the page templating in a multi-root structure. For example:

• Wechat WXML:

  <!--wxml-->
  <view wx:if="{{view == 'WEBVIEW'}}"> WEBVIEW </view>
  <view wx:elif="{{view == 'APP'}}"> APP </view>
  <view wx:else="{{view == 'MINA'}}"> MINA </view>

• Baidu SWAN:

<!-- template-demo.swan-->
<template name="tag-card">
    <view>
        <text>标签: {{tag}}</text>
        <text>昵称: {{nickname}}</text>
    </view>
</template>

<template name="person-card">
    <view>
        <text>位置: {{pos}}</text>
        <text>姓名: {{name}}</text>
    </view>
</template>

<template name="team-card">
    <view s-for="item, index in teams">
        <text>球队: {{index}} - {{item}}</text>
    </view>
</template>

<template name="age-card">
    <view>
        <text>年龄: {{age}}</text>
    </view>
</template>

• Alipay AXML

<!-- pages/index/index.axml -->
<view a:for="{{items}}"> {{item}} </view>
<view a:if="{{view == 'WEBVIEW'}}"> WEBVIEW </view>
<view a:elif="{{view == 'APP'}}"> APP </view>
<view a:else> alipay </view>
<view onTap="add"> {{count}} </view>

While Quick App template requires single root sturcture, but the template is combined together with the scripts and style in a single file (like Vue):

• Quick App UX

<template>
  <text>{{message}}</text>
</template>

<script>
  export default {
    private: {
      message: 'Hello'
    }
  }
</script>

<style>
  .demo-page {
    flex-direction: column;
    justify-content: center;
    align-items: center;
  }

  .title {
    font-size: 40px;
    text-align: center;
  }
</style>