Re: [xml-dev] The problems and the future of the web and a formalinterne

[Marcus Reichardt <u123724@gmail.com>]

Dear Raphael,

feel free to quote me in mails to those other recipients. Though I
don't think I've anything to say that those don't know already, seeing
as your recipient list includes TBL, Liam, and others.

Not sure W3C is the proper recipient for what you seem to push for,
simply because W3C has been in the web standardization game for most
of its existence, yet wasn't able to prevent the demise of the web
(not out of bad faith or something). It's my opinion that, If
anything, if you want to see a big-time XML+RDF agenda of the scope
you envisioned in your original mail, you'll risk evoking a bitter
controversy over past decisions, at best an "a fortiori" reaction
(such as TBL's SOLID project), but realistically nothing at all given
that most of the things have been discussed to death in their heyday,
but failed on the web. In fact, I believe W3C should disorganize under
its current statue, and make room for others, if only to let die the
illusion of the general population sitting at the table when it comes
to define the future of the web. But anyway, I look forward to your
detailed reply.

Not sure IETF as such is the right recipient either. After all, you
are free to create your own RFCs as you see fit. IETF hasn't prevented
(nor should it have) HTTP/2 and HTTP/3 with its scope creep/land-grab
of lower IP networking layers (which now turn out to be bogus eg.
Chrome dropping support for push resources), keeping controversial
features such as DoH in conflict with other RFCs. Leaving a situation
where new browsers and network stacks can only be approached by state
actors or very large corporations, which is exactly the kind of
situation that bona fide "standardization bodies" should strive to
prevent.

I wholeheartedly agree with your opinion that web apps (as opposed to
content-oriented web sites) should use programming languages for their
own sanity rather than a mish-mash of markup and programmatic
techniques a la React (which otherwise I don't think is half-bad at
all; it just wish e4x rather than jsx had "won"). But to challenge
that, the best way would be to establish a new JavaScript component
framework that folks would want to use rather than approach this from
a standardization angle; easier said than done, though.

Best regards,
M. Reichardt
sgmljs.net