This is a meta-suggestion. You won't appreciate that.
Are you aware that, if you call your proposal HTML6, you'll be forced to not only write down what you expect from your native MVC model, but also how it is meant to work with everything else and how everything else is expected to work on its own? Don't you feel it as a quite huge responsibility? For only one person, more so, and without any support on the side of programmers, browser vendors and so on (AFAIK)? I think that, with WHATWG Living Standard, W3 HTML5 & HTML5.1 we have enough HTMLs as of now.
Look, your proposal seems to revolve around a very specific number of subfeatures:
a <model> element, along with its newly-renamed <field> children
a <fixture> element containing JSON data origin
a mref attribute for content recall and a receiver attribute for model data exchange, on control-layer elements such as <a> and probably also <menuitem> in future
a model attribute on "target" elements, whose content is to be changed
In front of this all, I suggest you to drop out the HTML6 concept altogether. You don't need it. You need something to fit into current HTML standard, either as a feature proposal, or as something entirely new like SVG and MathML.
I know that being called the father of new HTML would be something to be proud of. But you yourself, alone, cannot honestly afford to face such a task. What you can do is to propose a different concept, we could say an HTML add-on. It will help you focus your ideas without having to rewrite all HTML logic (you don't really need it). It will also help you focusing your energy when you, or someone else working for you, will build a polyfill. You can't help doing it. Without a script reproducing your "native" model, believe it or not, accept it or not, you have failed before even starting. No browser vendor will ever invest time and programming effort in your ideas if you yourself aren't ready to support it, and no author will ever implement it waiting for an unlikely moment when implementation starts, achieves consensus and spreads wide enough to significantly replace non-compliant UAs (the fact that model allows fallback is totally irrelevant, as authors would like it to work as expected, not just to be there as a sort of totem).
As a starting point, I would suggest you to take all your new attributes and assign them to a whole array of new elements. Have a control layer? Don't specify it on <a>, put your mref and receiver attributes on a brand-new <control> element and wrap <a> in it. Have a view layer? Create a <view> element and wrap all the changing content inside it, so that you can also write less stuff (the model base can be the same for several elements changing at once, e.g. titles and articles' content, or image and captions). This is not strictly necessary - RDFa project succeeded in specifying its feature attributes on every element (it is focused on attributes, though) - but it will help you keep the project easy to maintain.
Don't be fooled by the length of my message - it's always 2cents worth.
This is a meta-suggestion. You won't appreciate that. Are you aware that, if you call your proposal HTML6, you'll be forced to not only write down what you expect from your native MVC model, but also how it is meant to work with everything else and how everything else is expected to work on its own? Don't you feel it as a quite huge responsibility? For only one person, more so, and without any support on the side of programmers, browser vendors and so on (AFAIK)? I think that, with WHATWG Living Standard, W3 HTML5 & HTML5.1 we have enough HTMLs as of now. Look, your proposal seems to revolve around a very specific number of subfeatures:
<model>element, along with its newly-renamed<field>children<fixture>element containing JSON data originmrefattribute for content recall and areceiverattribute for model data exchange, on control-layer elements such as<a>and probably also<menuitem>in futuremodelattribute on "target" elements, whose content is to be changedIn front of this all, I suggest you to drop out the HTML6 concept altogether. You don't need it. You need something to fit into current HTML standard, either as a feature proposal, or as something entirely new like SVG and MathML. I know that being called the father of new HTML would be something to be proud of. But you yourself, alone, cannot honestly afford to face such a task. What you can do is to propose a different concept, we could say an HTML add-on. It will help you focus your ideas without having to rewrite all HTML logic (you don't really need it). It will also help you focusing your energy when you, or someone else working for you, will build a polyfill. You can't help doing it. Without a script reproducing your "native" model, believe it or not, accept it or not, you have failed before even starting. No browser vendor will ever invest time and programming effort in your ideas if you yourself aren't ready to support it, and no author will ever implement it waiting for an unlikely moment when implementation starts, achieves consensus and spreads wide enough to significantly replace non-compliant UAs (the fact that model allows fallback is totally irrelevant, as authors would like it to work as expected, not just to be there as a sort of totem).
As a starting point, I would suggest you to take all your new attributes and assign them to a whole array of new elements. Have a control layer? Don't specify it on
<a>, put yourmrefandreceiverattributes on a brand-new<control>element and wrap<a>in it. Have a view layer? Create a<view>element and wrap all the changing content inside it, so that you can also write less stuff (the model base can be the same for several elements changing at once, e.g. titles and articles' content, or image and captions). This is not strictly necessary - RDFa project succeeded in specifying its feature attributes on every element (it is focused on attributes, though) - but it will help you keep the project easy to maintain.Don't be fooled by the length of my message - it's always 2cents worth.