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

[John Cowan <johnwcowan@gmail.com>]

On Fri, Jan 1, 2021 at 2:37 AM Raphaël Hendricks
<rhendricks@netcmail.com> wrote:

> All
> this was being done through the working on XHTML 2.0 draft, RDF/RDFA,
> the semantic web in general (which would allow better indexing and
> content reuse and which would be mostly based on the previously
> mentioned languages),  XSLT, XForms, XML in general, XInclude, and so
> on.

> [...] server-side dynamic capability with static-only client
> side, except for form-validation through XForms, XML to XML
> conversion through XSLT and timing/events thorough XML events and
> SMIL animation, or where client side dynamic capabilities are
> declarative only, with no imperative support) [... and more and more and more ...]

The difficulty with all that is that it is just horribly complicated
and constantly growing, one technology after another.  What happens
then is that it becomes just about as hard to write a browser for
XHTML-2.0-plus-long-tail than it is to write on for HTML5/CSS/JS, if
not more so.  This creates an oligopoly of client software, because
nobody except people with strong first-mover advantages can afford to
write one.  This I consider to be a Bad Thing.

> It however needs to
> be stated that there are legitimate reasons to wish to run software
> operating in a client-server split model, that is not the problem.
> The problem is that bastardizing the WWW and the technologies
> supporting it is not the proper way to answer this legitimate need.

I agree entirely.  But piling up another huge stack is not the way to
do this part of the job either.

If we instead look at design from a perspective of simplicity, we get:

JSON and when needed MicroXML for structured data.

Gemini (see http://gemini.circumlunar.space for details), a protocol a
little more complex than Gopher, but adding mandatory TLS encryption
(currently 1.2 or 1.3; in future 1.3 only), content retrieval by URL
(which allows virtual hosting, protocol gatewaying, etc), client
certificates as a universal authentication mechanism, and responses
tagged with media types.

In addition, Gemini comes with a new hypertext format, text/gemini,
which is also designed to be simple.  In a year and a half of very low
voltage development, dozens of clients and servers have been made
available already.  Gemini clients, rather than document authors,
decide how texts are to appear.  However, the Gemini protocol can
support arbitrary media types including HTML.  There are two sister
protocols, Titan for uploading content and Dioscuri for sending and
receiving entity bodies in a single transaction.  However, there is no
need for Gemini browsers to support either of them.

> There is
> also a need for a technology to run client-side software that
> connects to remote software running on the server; this type of
> technology, with client software connecting to software running on a
> server, is the right way to handle transactional operations such a
> banking and stock buying as well as online shopping;

I agree.  In order to manage this from the same simplicity and safety
viewpoint, I believe that a new programming language is needed: easy
to use for all programmers from beginners onward, with textual and
bytecode representations, and pre-sandboxed rather than running in a
sandbox.  I am working on such a design:  see
<http://tinyurl.com/avsl-nutshell>.  AVSL is a temporary name, meaning
"A Very Simple|Small|Safe Language".

Comments on the language can be sent to me.



John Cowan          http://vrici.lojban.org/~cowan        cowan@ccil.org
If I have seen farther than others, it is because I was standing on
the shoulders of giants.  --Isaac Newton