Re: The problems and the future of the web and a formal internet technology proposal

If you are going to propose a new communications media, you would do well
to first learn how to communicate.

I have no idea what problem you are trying to solve having read the first
three screenfulls. And I have a really big screen.

Changing an infrastructure once deployed is near to impossible. Nobody is
going to switch from email or the Web to a new platform that meets the same
needs. The only way that an established technology like fax disappears is
if a new technology appears that meets the needs of a community that is not
served by legacy systems which is capable of being extended to replace the
legacy system over time.

Even then, it took over 20 years for MIME to replace fax and even now there
are holdouts.



On Mon, Jan 4, 2021 at 10:22 AM Raphaël Hendricks <rhendricks@netcmail.com>
wrote:

> The last decade of change in internet technologies has brought up
> significant change and with it, some new unadressed issues. In 2005,
> there has been a schism between two groups in their idea for the
> future of one specific internet technology, namely the web. I am
> adressing this message to several concerned groups and individuals
> about some serious problems which have plagued the web as it is. In
> this message, I am going over the problems and making a formal
> proposal to replace the World Wide Web in its current form with two
> new technological platforms as well as replacing the World Wide Web
> consortium with two new consortiums, one for each new technological
> platform; this message will be of particular interest to XML people,
> Semantic Web people and anti-DRM people, but also, to some degree, to
> privacy-advocates and accessibility-advocates as all these points are
> adressed, the message will also be of interest to the IETF since I am
> suggesting some changes in the administrative structure of some
> internet technologies. I encourage everyone reading this message to
> diffuse it as widely as possible, the more people read it, the better.
>
> Message for Sir Timothy Berners-Lee: your ideas for basing the future
> of the web on XML, XPath, properly structured data and documents, the
> semantic web, and the openness principle were really great; it is a
> shame that such a vision never came to be implemented, I am reviving
> your ideas in this proposal again, for one of the two platforms,
> because I believe that they are worth another consideration.
>
> On one hand, there were the usual W3C working groups preparing the
> furthering of the traditional web principles, namely accessibility,
> ease of indexing and referencing, separation of content, meaning and
> presentation, making sure that any content is not limited to a
> specific use by allowing a proper structure for the content, allowing
> easy archiving, implementing mandatory validation, and so on. 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. There were working to reduce the need for ECMAScript and, more
> importantly, Javascript (partly through technologies such as XForms,
> XPath and XML Events), which is a good thing as scripting works
> against the previously stated goals and should only be used as a last
> resort (on top of all, Javascript is a proprietary language (owned by
> Mozilla), which makes it even worse a choice, while ECMAScript, which
> is only a subset of Javascript, is, at least, a standard (ECMA262),
> which makes it a lesser evil). Work was being done to advance
> development of aural style sheets as they had rightfully understood
> that content may not exclusively be used by generating its visual
> rendering. Those working groups were also trying to cut clean with
> the tag-soup era. In such a vision, there was, of course, no place
> for DRM as it goes against the openness which the above stated goals
> tries to achiveve. It is well known that information wants to be
> free. The attempt to switch to XML and the semantic web can be seen
> as an attempt to go back to the original vision that Sir Timothy
> envisioned when he chose to connect his web technology to the wide
> internet in 1991 (making information freely available (think free-
> speech, not free beer) and easely usable for any use without use
> restrictions). The tag-soup era that preceeded can be seen as a move
> away from that vision.
>
> On the other hand, there were some entities which were opposed to the
> switch to XML and the semantic web. They stated that those approach
> were too document-centric and that they wanted to create a technology
> more adapted to webshops, forums and so on, they wanted to better
> support interactivity than what was proposed with the switch to XML
> and the semantic web, they wanted to support client-side programming
> (as opposed to the move away from scripting), they wanted to support
> client-side dynamically updated content and dynamic capabilities (as
> opposed to the 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). They were also
> concerned with the fact that the strict well-formedness and
> validation requirements of the XML technology made integration with
> several server-side programming languages problematic to say the
> least. Everyone has sawn that XHTML webpage which was valid 9 times
> out of 10 and invalid 1 time out of 10 due to the page having dynamic
> content wich at times would make the page invalid or badly-formed.
> This was due to most of those server-side languages being based
> either on the approach of inserting program code within a to-be-
> enriched incomplete page, which makes a page whose validation cannot
> be wholely be verified or around the concept of generating the page
> source by generating the markup text (as a sequence of characters) in
> which case only examples of the script execution result can have
> their validation tested but validation cannot be garanteed, this
> instead of generating the page structure (through DOM core methods or
> using XPath based technologies). The server-side programming language
> which, at the time were the W3C was trying to switch the web to XML,
> was the most popular, PHP, was particularly affected by this, and
> languages such as Perl, Python and ASP were not in a much better
> state. Now, before someone points it out, yes, there has been cases
> when carefull programmers were able to use languages, such as PHP, to
> implement some proper server-side dynamic capatilities by having php
> files with no XML content, and, for each page, a small user-
> modifiable XML config file serving to map variables to XML attribute
> values or tag content, one or more XML templates, an XSLT module to
> allow calling an XSLT interperter from the main language and an XSLT
> transform sheet, applied to the template and used to generate the
> well-formed, perfectly valid XHTML page, these cases were the
> exception rather than the norm, while pages which were usually valid
> but without a garantee that the dynamic features would not break the
> validity (cases which would occur occasionnally), were the norm.
> There were server-side technologies with proper XML support and
> integration (such as, for example, for advanced capabilities: JSP/
> Servlets (and debatably Ruby Electric XML), for intermediate
> capabilities: server-side javascript, for rudimentary capabilities,
> XInclude) but many server-side programmers didn't want to switch to
> those languages, part of the resistance against switching the web to
> XML certainly partly, but not only, comes from there. The entities
> which were opposed to the switch to XML and the semantic web did not
> want the WWW remaining a web of documents interconnected with
> hypertext links (and extended through for form-validation through
> XForms, XML to XML conversion through XSLT and timing/events thorough
> XML events and SMIL animation), this being the too-document-centric
> criticism. They wanted to turn the web into a technology to run
> software in the browser. These entities were mostly Google and
> several major browser makers and they went on to establish the WHATWG
> to create the HTML5 specification, promote the XML-RPC format and
> create the JSON and JSON-rpc formats, all of which would serve as a
> basis to implement that change.
>
> The WHATWG idea of turning the web into a platform to run software in
> the browser was a stupid and extremely bad idea. 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.
> The proper way to meet this need is to create a dedicated
> standardized platform to run client software connecting to server
> software over the internet, but with the said platform being separate
> from the web. There is a need for a technology to make openly
> available hyperlinked documents, with the documents using XML markup
> to indicate their structure and using RDF or RDFa to indicate
> semantic information, and using SMIL aniation / XML events to generte
> declarative animations, and using XForms to validate user-input data
> against XPath expressions or an XML Schema before using the said data
> to further the content available as hyperlinked documents. 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; it is also well
> suited for highly interactive applications, such as playing networked
> computer games. There should be two different platforms for two
> different uses, not one general purpose monster.
>
> In cases such as real-time stock buying, having a remotely executely
> executable application should not be seeen as being incompatible with
> having a real-time XML feed with the raw data, with a basic
> stylesheet which allows easier reading for those who prefer to read
> the raw data; it should be the objective to always make the raw data
> available where possible in parallel with having the data accessible
> through the client-side application. For example, one may wish to
> access the raw standard bus schedules of a city or the raw realtime
> bus data feed (with a basic stylesheet to ease reading) rather than
> have to go through the official bus operator supplied online
> interface and should not be prohibited from doing so; the said raw
> data could then also be used for other uses than online reading (ex:
> statistical).
>
> As stated above, there is a need for a technology to make openly
> available hyperlinked documents, with the documents using XML markup
> to indicate their structure and using RDF or RDFa to indicate
> semantic information, and using SMIL aniation / XML events to generte
> declarative animations, and using XForms to validate user-input data
> against XPath expressions or an XML Schema before using the said data
> to further the content available as hyperlinked documents; this
> allows easy indexing, using RDF/RDFa to derive meaning as opposed to
> having to extract the information from human readable documents
> containing no extra annotation for computers; this would allow many
> search engines to be easely implemented bringing competition in the
> field as opposed to having an oligopoly made out of a few companies
> which have access to the advanced technology to extract data from
> human readable content without machine annotations, technology which
> nonetheless still produce search results inferior to that of a
> simpler search engine indexing only sementic-information-containing
> documents. Having a unified URL+URN=URI framework is important in
> information sciences and archivivsm, abolishing the URI approach to
> go back to old-style URLs as was done with HTML5 (they even re-
> introduced the URLs starting by the javascript: pseudo-protocol
> designation, which is beyound the limits of decency) is plain stupid.
> It is essential that formatting and presentation information not be
> used to convey the structure of the document, using said presentation
> information to convey structure limits the use of the data inside of
> the document to that originally thought by the author but the data
> then cannot easely be used otherwise. A user may wish to turn off
> stylesheets for various reasons (for example because the user has
> poor vision) and the document structure should still be easy to grab
> when seen with the user-defined stylesheet inside the browser, this
> is not possible if the document content is not properly structured;
> not surprisely, XHTML documents tend to be much better structured
> than HTML documents as, in XML, the structure is everything. It is
> also baffling that none of the major websites uses aural stylesheets
> and that most browsers don't support them even though page content is
> meant to be independent of the rendering method and having an audio
> rendering of a page is a legetimate use of the content, aural
> stylesheets should be used and supported as standard just as widely
> as visual stylesheets. Moreover, having content not tied to an
> expected use allows unexpected new uses to come up ulteriorly. For
> example, if various sellers put up catalogs of their products online
> and encode the data about the products properly using a generic
> fashion, even if the catalogs were meant to be read by humans, they
> can easely be used by price comparison tools or they can be easely
> used by statistical tools to study the historic evolution of prices.
> If the catalog documents put online are only human-readable with too-
> poor-a-structure to be easely analysed by computers, such extra uses
> cannot come-up. Having documents which are only human-readable,
> having a structure insufficient to be analysed by computers has a DRM-
> lite effect by restricting the uses of the said documents. It is
> therefore obvious that having content not being made for a specific
> use is highly beneficial. Such a technology would likely be deployed
> for uses such as publishing documentation, governement websites,
> university/faculty/department/professor websites, company product
> documentations, blogs, amateur websites, digital document archives
> (using XForms for searching) and so on. It could also contain content
> which is available against a payment but where, after supplying the
> payment, the available content is non-usage-restricted. It would not
> be used in cases when the content maker wants to restrict the usage
> of the content but this is a good thing as such usage-restricted
> content has no place on such a platform.
>
> A technology to run client-side software connecting to server-side
> software over the internet supplying a standard method for the said
> software to be transferd to, as well as deployed and run on the
> client is highly useful. Such a technology should not use a page-
> based content structure. Making pages out of content only makes sense
> if the content is constant and indexable, which is obviously not the
> case for dynamically generated or dynamically updated content. Such a
> technology should not use ECMAScript or Javascript as its language
> since it is inappropriate for the use, Javascript was originally
> created as a scripting language, not a programming language, it was
> meant to add a bit of dynamic capabilities to web pages, not to write
> software (hence its reputation as a hackish language among those
> which use it to write real software, javascript is a good scripting
> language but a poor programming language); on a platform allowing
> client-side software to connect to server-side software, the client-
> side software should be written using a proper programming language.
> Cases such as real-time stock prices and real time bus/tramway
> locations are good examples of time-varying content where client-side
> dynamic capabilities make sense but putting the content in permanent
> static pages doesn't. Cases such as inventory management, online
> banking and product purchasing are good examples of highly-
> transactional content where client-side dynamic capabilities are
> useful but putting the content in pages for indexing or not-yet-
> invented future uses has limited use. Cases such as running networked
> computer games or running non-networked computer games are good
> examples of highly interactive content where client-side adequate
> software capabilites with hardware acceleration accessible by the
> client-side software is useful but trying to structure the content
> into pages makes no sense and the content cannot truly be indexed.
> All these examples show that there are cases where a technology
> distinct from the one to create a web of hyperlinked, structured and
> semantically-encoded documents is highly needed and that such a need
> doesn't nullify the one for the previously stated web of hyperlinked,
> structured and semantically-encoded documents, since the use-cases
> for each are highly different.
>
> The HTML5/javascript/JSON-rpc approach is a real problem. It meets
> neither of the two needs properly. For the structured and, perhaps,
> semantically encoded, hyperlinked document need, the HTML5/javascript/
> JSON-rpc is a disaster. The rpc capabilities make for dynamic content
> impossible to index. JSON data doesn't allow content indexing and
> reuse as easely as XML data. The reliance on javascript make the
> documents harder to analyze and index, and ties the content to a
> single use, which is online viewing (often visual only, without even
> supporting audio rendering). Cookies, while not strictly part of
> HTML5 (they are part of HTTP/HTTPS) are nonetheless a feature coming
> from the tag-soup era which should be phased out, instead of that,
> HTML5 introduced an enhanced version of the concept in the form of
> webstorage. Cookies are almost exclusively used for three uses,
> namely sessions, interwebsite-tracking and intra-website analytics.
> Session cookies are an unnecessary and absurd mechansim to implement
> sessions which is less safe and less sensible than the built-in HTTP
> session mechanism, which should be used instead. Intra-website
> analytics may be a privacy issue, webmasters requiring intra-website
> analytics should either limit themselves to statistics which do not
> require users to be traced or be upfront about the fact that users
> must open a session, use the HTTP session mechanism for this and be
> clear that their usage data will be logged and analyzed, doing
> otherwise is dishonest and a lack of transparency, in a way, it is
> requiring users to create a identifier without being open about it
> and making them open sessions through the back door. Inter-website
> tracking cookies are a privacy breach and represent a practice whihch
> needs to be abolished. The few other cases where cookies are used,
> namely where keeping variables from one page to the next is
> necessary, can easely be handled by using address rewriting instead
> of cookies. Webstorage brings the same problems as cookies but to a
> greater extent. The DRM inclusion in HTML5 is the antithesis of the
> openness goal. It intentionally restricts usage when the maximum
> openness goal requires implementing technology to facilitate ease of
> access and facilitate new and unexpected usage of the content,
> removing as much technological-limitation-derived usage restruction
> as possible. DRM also makes archival problematic. While not part of
> HTML5, the HTTP/2 protocol often used to transfer the said content,
> breaks the protocol layering principle and is a problem because of
> this. The WHATWG even had the indecency to reintroduce an element
> coming from the tag-soup era and having never been part of any
> standard HTML or XHTML version, namely the embed tag. From all these
> elements, it is obvious that the HTTP/2/HTML5/JSON/javascript/JSON-
> rpc/ based web infrastructure is ill-suited to answer the need for an
> open and privacy respecting web of structured and, perhaps,
> semantically encoded, hyperlinked document described previously. If a
> news/blog/text+image website cannot be read without enabling
> javascript, it fails, unfortunately, such cases have become common,
> yet people create "webapps" which need to be "run" just to access a
> page of content, this is the kind of situation brought by HTML5/JSON/
> javascript/JSON-rpc. The interest for XMl has not died when the W3C
> decided to base the future of the web on HTML5, the companies and
> other entities which were previously behind the XML effort switched
> most of their XML efforts to the OASIS group, which is concerned with
> the use of XML for document-centric/data-centric uses (but not
> diffused on the web); this is proof that interest for the XML
> structured/data-centric approach continued after the W3C decision.
> For the other need, that of running software on the client-side which
> connects to software running on the server (which is what "web
> applications" are trying to do), HTML5/JSON/javascript is just as
> badly suited to the need. Trying to turn HTML/CSS/XHTML/XML into a
> application writing platform was trying to trun a squirrel into a
> dinosaur. As stated previously a page based structure is not adapted
> for this use, yet HTML5 retains the page approach. HTML5/JSON/
> javascript/JSON-rpc is no longer a propper squirrel, nor did it turn
> in a proper dinosaur, it is some sort of ugly chimera.
>
> When creating the new HTML working group tasked with developping
> HTML5 Sir Timothy Berners-Lee said that:
>  > Unlike the previous one, this one will be chartered to do
>  > incremental improvements to HTML, as also in parallel xHTML.
> No real efforts have in fact been put in XHTML in the last 12 years,
> while there is a theorical XHTML5, it only exists on paper.
> About forms he said that:
>  > The plan is, informed by Webforms, to extend HTML forms. At
>  > the same time, there is a work item to look at how HTML forms
>  > (existing and extended) can be thought of as XForm
>  > equivalents, to allow an easy escalation path. A goal would
>  > be to have an HTML forms language which is a superset of the
>  > existing HTML language, and a subset of a XForms language
>  > wit [sic] added HTML compatibility.
> All of this has never happened, in fact the XForms 2.0 specification
> was never completed, the most recent draft is from 2010. The attempt
> to use a new HTML working group to gradually move the standard to a
> point where the switch to XML would be easier never worked, the
> WHATWG acted as if they are the only ones in charge, refusing to
> address concerns addressed by the other W3C people, which brought
> long fights where the WHATWG would continue fighting until the other
> side would give up; they acted as though the only role for the W3C
> was to approve what the WHATWG was doing, giving it legitimacy, and
> they have sadly succeeded; Ian Hickson is particularly guilty in this
> case.
>
> Once it has been established that there is a need to put an end to
> the web as it is and create two succeding platforms, one, a new and
> reborn web based on XML/XPath/RDF/RDFa for data structurally and,
> eventually, semantically encoded and the other one, a remote
> application execution platform based on some appropriate programming
> technology, one may wonder why the change should be done now. Some,
> especially those whose web development falls in the second use, that
> of a remote application execution platform and probably not those
> whose web production falls in the first use, may think that the
> current web is usable enough for the said purpose. To address this,
> one must first remember that moving away from XML/XPath also means
> moving away from the structurally and semantically encoding
> technology which is problematic for the first of the two needs, that
> of the said structurally and semantically encoding technology,
> second, for the remote application execution need, the ill-suited
> nature of the current web, with the amount of needed workarounds it
> brings, means a huge amount of anually wasted manpower worldwide. The
> number of lost man-hours on an annual basis which are lost wordwide
> due to the issue of trying to get the web technologies to do
> something for which they are not suited is probably in the millions.
> The other big reason for doing the change now is that the underlying
> internet infrastructure is about to change, and it would be best to
> design the remote application execution platform around the new
> upcoming infracture. The said infrastructure change is the soon-to-be
> widespread deployment of edge-computing. The deployment of edge-
> computing will shift the approach from a client/server operation to a
> client / edge-server / remote-server operation; the adoption of 4.5G
> and 5G telephony will popularize the use of edge computing, which is
> expected to play a significant rôle on those networks. Of course,
> some more workarounds could probably be founds to operate the current
> web platform with the newly running edge-servers; however, the proper
> solution would be a technological redesign, it really would make
> sense to design the remote application execution platform for this
> model (client / edge-server / remote-server) from the beginning.
> There should be a standardized method for a client terminal to send a
> request to the closest edge-server with the identity of the service,
> available from a remote-server, service for which the edge-server
> would then download its portion of software (the part to be run on
> the edge-server), as well as that of the client, through a
> standardized mechanism, the standardized technology should also
> define how the edge-server is to send to the client its portion of
> the software (the part to be run on the client) coming from the
> remote-server and finally it should define the format of the software
> code. This would make remote application execution platform adapted
> to the presence of edge-computing. For the other need platform, that
> of a new and reborn web based on XML/XPath/RDF/RDFa for data
> structurally and eventually semantically encoded, there is no use for
> edge-servers, it is best to have the client computer contact directly
> the remote and sole server with the said remote and sole server doing
> most of the processing and simply serving the data to the client
> computer, with the only processing done on the client being for XSLT/
> XPath/XForms/SMIL-animation/XML-events. The current World Wide Web
> consortium should be replaced by two new groups one to develop each
> of the succeding platforms. The current World Wide Web, from a great
> organization has turned into an ugly three-headed monster, one head
> is the semantic web / XML / RDF people, the second head is the WHATWG
> people trying to turn the web into a remote application execution
> framework, the third and final head is the copyright industry. The
> first new consortium, developping the structured and semantic web,
> based on XML / XPath / RDF / RDFa, should be a joint IETF/OASIS
> consortium, since the IETF is generallly commited to the openness of
> technologies and OASIS is where most work around XML has happened
> since XML has started leaving the web, this would help ensure good
> integration with other XML technologies and the proximity with many
> XML people (from OASIS) would help jumpstart the XML uptake; of
> course, Sir Timothy Berners-Lee would be the proper chair for the
> consortium. The second consortium concerned with creating a remote
> application execution platform should be a joint consortium between
> the IETF and a second group, the WHATWG being an option but the
> Khronos group being preferable (the platform function would fit well
> in its "connecting software to silicon" mandate), even the Object
> Management Group could be chosen. The following two paragraphs
> contain formal proposals for the subsequent two platforms which would
> badly need to succeed to the current WWW.
>
> In creating the platform for the structured and semantic web, based
> on XML / XPath / RDF / RDFA, there are at least two sensible choices
> as a basis for the central language for the platform (meant to
> finally replace HTML). One is to resurect the XHTML2.0 working draft
> since, after all, the people behind it are competent and did good
> work and the XHTML2 was done with the very same objective which would
> be pursued by this platform. The second obvious sensible choice is to
> break-down some XML-based standards from OASIS, such as Docbook, into
> modules, taking all the modules which cover needed functionalities
> and completing the language with new modules, this would allow high
> integration with the other XML standards developed at OASIS (the main
> XML development group at the time). Of course, a fully new language
> could also be designed, but it would provide neither of the
> advantages of the previous two approaches. It is probably best not to
> call this XML-based new language XHTML as people see the letter
> sequence HTML (regardless of the leading X) they expect the language
> to be compatible with HTML4 and will fight anything which isn't (for
> the XHTML2.0 draft, it was likely a mistake not to have changed the
> name). Of course, the new consortium developing the platform should
> take-up the development of the core XML, XPath, RDF/RDFa (and even
> XForms and XInclude) languages. Since so many people seem to be
> obsessed with support for scripting/programming, it is probably a
> good idea to develop a complementary fully declarative scripting
> language, based on XPath, XML Events, and SMIL Animation, with some
> extra XML markup, to allow scripting which is fully XML/XPath based
> and avoid seing external languages being grafted on top of the
> platform as has happened to HTML with javascript. It is important
> that there is no cookies/webstorage, there should however be the
> option to use the protocol session mechanism either that of HTTP or
> of a new XML-based protocol (see the subsequent part of this
> paragraph). It would also be beneficial to define standardized
> styling mechanisms, both for visual stylesheets and
> aural.stylesheets. The visual styling mechanism should get rid of the
> GUI building components available in CSS3. For the aural stylesheet
> mechanism, one option is to use the already existing, but never
> implemented, W3C aural stylesheets, it would have the inconvenient of
> not being XML/XPath based, a better approach, however would be to
> start with an XML reformulation of the W3C aural stylesheets and
> replace the current selectors with XPath based selectors, this would
> give a language using XML for the styling definitions and XPath for
> the selectors. For the visual stylesheets, there are several possible
> options. One is to use CSS3 with the GUI building parts removed, it
> would however have the inconvenient of not being fully XML/XPath
> based, another option is to combine an XML reformulation of the CSS3
> styling definitions with XPath selectors, this would supply a fully
> XML/XPath solution, another option is to use XSLT/XSL-FO, another
> option would be to use XSLT to generate SVG data for rendering (there
> is unfortunately some overlap in capabilities in SVG and XSL-FO even
> though XML languages should ideally, instead of reimplementing
> functionalities, import modules from other languages). Of course, a
> fully new XML and/or XPath styling language can be created, however
> the previous approaches would allow better integration with existing
> technologies than a new language would. The visual styling mechanism
> should mandate the definition of two styling types: paper-like and
> video-like, chosen automatically based on a browser-setting
> parameter, forcing all users to have a paper-like rendering as is
> currently done on the web is not the best option; a video-like style
> uses pale text on a dark or coloured background with characters based
> on thick lines, with no serifs or limited serifs (terminal-font-
> like), may optionally use character outlines for readability on any
> image backgrounds, and can be easier to read for some users with
> impaired sight as well as be more suited to some display types, a
> paper-like style uses dark text on a pale background with characters
> of varying width and varying serif styles; most webpages and current
> GUIs can be described as paper-like while some vintage GUIs as well
> as most CLIs can be described as video-like. Mandating both in a
> visual stylesheet would allow the user to choose which to use through
> a simple browser setting. It is also worth considering wether the
> consortium should develop, for the platform, a new protocol to
> replace the HTTP(S), especially the SPDY based HTTP/2 which is
> problematic, protocol which would be XML-based, one possibility would
> be to have SOAP-over-TCP, similarly to the way that OASIS developped
> SOAP-over-UDP; again, it would be a good idea not to call this HTTP
> (S) to avoid raising false expectations. If combining SOAP-over-TCP
> with an XML session mechanism and XHTML2 / RDFa with XSLT / XForms /
> SMIL-animation / XSLT / XSL-FO or SVG / XML Events and SMIL Animation
> it would finally allow to only have XML/Xpath for the whole stack
> with no other technologies. Of the two platforms, the one for
> hyperlinked structured documents, possibly semantically encoded,
> documents based on XML/XPath, is the one to keep the name "the Web"
> or the "World Wide Web", since it would implement what the Web was
> meant to be. The other should be called something else, for example
> Online Service Platform (OSP).
>
> The other platform, to implement remote software execution should be
> integrated with edge computing. There should be a standardized method
> for the client to contact the edge-server and indicate which service
> is to be accessed from a remote-server, the standard should specify
> the mechanism to download the edge-server code and client code from
> the remote-server to the edge server (and mechanisms for caching both
> on the edge-server when possible) and the mechanism to download the
> client code from the edge-server (previously received from the remote-
> server) to the client (on a per-module basis instead of all at once,
> module method which could also be used to transmit data as modules,
> data to be used by the software running on the client). There should
> be a mechanism for the client to request that the edge-server open,
> on its behalf, a session on the remote-server, transmitting its
> identity to the remote server, this would allow a given client
> operator to have a permanent account on the remote-server, even
> though the operator may use differing clients connecting to different
> edge-servers over time. Since edge-servers are being used, this is
> where the bulk of the processing workload should lie. The client
> processing workload should be mostly limited to rendering and
> handling user interaction with a few extras here and there, this
> allows to reduce power usage at the client-point (useful for portable
> devices), it also allows to reduce the needed processing power,
> except for audio/graphics rendering circuits, at the client point
> (reduces the manufacturing cost of the client devices). The remote-
> server processing workload should be limited to that which cannot be
> done on the edge-server, such as storing user data between sessions,
> serving the edge-server and client code to the edge servers,
> processing that which only needs to be calculated once before being
> sent to all the connected edge-servers and relaying data between the
> connected edge servers; pushing most of the load on the edge-server
> allows a lower latency operation for the client. There should also be
> a mechanism for the client to indicate its device class to the edge-
> server and the information should be available to the software
> downloaded from the remote-server and running on the edge-server;
> sensible device classes allowed should include at least the
> following: small_touchscreen, big_touchscreen, pointer_based,
> remotecontrol_based and maybe others. There should be two more flags
> accompanying the device class; the first one being the presence or
> absence of a keyboard, this would allow the software to modify its
> interface when no keyboard is available so as to reduce the need of
> the (hard to use) onscreen keyboard to the minimum and to increase
> the reliance on the keyboard when a physical keyboard is available;
> the second one being the presence or absence of a joystick/joypad,
> some game software may require a device class other than a
> small_touchscreen as well as either a pointer_based device class or
> another class accompanied by a keyboard or a joystick/joypad to be
> playable and may need to check for this. When the client connects to
> the edge-server, there should be a method for the client to transmit
> to the edge-server a parameter indicating its prefered colour scheme
> and text style (parameter made available and used by the software
> coming from remote-servers and running on the edge-server and
> client), with two options being available, video-like and paper-like;
> forcing all users to have a paper-like rendering as is currently done
> on the web is not the best option; a video-like style uses pale text
> on a dark or coloured background with characters based on thick
> lines, with no serifs or limited serifs (terminal-font-like), may
> optionally use character outlines for readability on any image
> backgrounds, and can be easier to read for some users with impaired
> sight as well as be more suited to some display types, a paper-like
> style uses dark text on a pale background with characters of varying
> width and varying serif styles; most operators of remotecontrol_based
> device class clients would likely opt for the video-like mode and
> operators of other device classes would use either, but users may
> have varying reasons, as stated previously, to choose either mode.
> Edge-server operators could maintain a list of problematic remote-
> server operators, used as a black list, which can help avoiding
> client operators being defrauded by unknowingly connecting to
> fraudulent online services. The platform should include a
> standardized payment mechanism used for services operated on a
> commercial basis. When a client operator opens a trasaction requiring
> a payment with a remote-server operator, there should be a mechanism
> for the edge-server operator to bill the client; the edge-server
> operator could then act as an escrow and wait until the service has
> been supplied in a satisfactory manner to transfer the funds to the
> service provider / remote-server operator; this will push the service
> providers / remote-service providers and client operators to behave
> properly as opposed to the far-west that is the current state of
> online business. For cases where client-devices need to have managed
> or limited payment initiating capabilities such as in internet cafés
> (where a client operator would first need to pay the café employee to
> make funds available before initiating a payment), there should be a
> mechanism for one client-device to manage the payment initiating
> capabilities of other client devices. When remote-servers announce
> the services which are available from them, there should be a
> mechanism to indicate if the service is fully free, fully paid or
> partly free and partly paid, it should also indicate if the free part
> has advertizing or not and if the paid part has advertizing or not.
> The mechanism should also allow indicating to which standardized
> category it belongs, there should be at least the following six
> categories (and maybe others): online-shopping, for-profit
> transactional accounts (banking, commercial utilities, etc.), non-
> commercial accounts (accounts at municipalities, provinces,
> countries, NGOs), non-commercial media, commercial media and other.
> This would allow easy classifying and finding of the services. The
> standard should specify some programming languages for execution on
> the edge-servers and clients. There should be several interpreted
> programming languages supported as standard and an intermediate
> representation language to support software written in other
> languages and compiled to the intermediate representation (this will
> avoid having one or more of the interpreted programming languages
> serving as a de facto intermediate language which is inefficient).
> For maximum portability and interoperatability, the intermediate
> representation language should be text based rather than binary, it
> should be endian-neutral by implementing program adressing using
> labels instead of hard adresses and data adressing by using named
> variables instead of hard adresses, by supporting strings as a native
> type and having numerical values (signed/unsigned ints/floats of
> varying lengths) specified in hexadecimal encoded big endian format
> (the most readable) and converted to the native binary format of the
> appropriate endianness by the back-end compiler running on the client
> and which generates the binary which is to run on the client-hosted
> virtual machine. The intermediate representation language should
> ideally be statically and strongly typed, with type handling left to
> the frontend compiler (the feaseability of handling type definitions
> and conversions in a compiler has been shown with the Nim and Crystal
> compilers). On the other hand, the intermediate representation
> language should be garbage collected as leaving the memory management
> to the software developper or the front-end compiler risks corrupting
> the memory of client-device (unless there is a garantee that the
> client has memory protection); the client should handle memory
> through compile-time garbage collection (in the back-end compiler
> producing the binary code for the virtual machine) or run-time
> garbage collection (inside the virtual machine). There should also be
> a mechanism for loading shaders on the client GPU from within the
> intermediate representation language, the best shader format probably
> being a slightly modified SPIR-V assembly, which would be endian-
> neutral, again by handling code adressing through labels instead of
> real addresses, by handling data adressing by using named variables
> instead of real addresses and by having numerical values written in
> big-endian format (the most readable) in the transfered code and
> converted to the final endianness by the client device before
> assembling the shader. For the interpreted languages, endian-
> neutralness can be handled by first choosing languages which do not
> allow direct manipulation of addresses, which is the case of most
> high engough languages and second by again having numerical values
> written in big-endian format (the most readable) in the transfered
> code and converted to the final endianness by the client device
> before interpreting the software code. The interpreted programming
> languages should have the choice to load the same type of GPU shader
> as the intermediate representation language or use a mid-level
> library. There should be hardware-accelerated OpenMAX DL (with a
> generic DCT/IDCT extension not tied to a particular use unlike the
> current versions which are for JPEG, MPEG4 AVC and MPEG4 SP only) /
> OpenSL ES, Vulkan and OpenVG available. As for the choice of
> interpreted programming languages, the following list might be a
> sensible choice: Python, which has become the high-level interpreted
> programming language of choice in the unix-like OSes community, Ruby,
> which positions itself as the competitor to Python and is used by
> those who wish to avoid Python, ISLisp as those programmers who do
> not identify with the unix culture often are adepts of Lisp and
> ISLisp is lightweight (and as such better suited to this use case)
> and consists of the common subset of the major Lisp variants,
> finally, the language Mercury, as it would put a purely declarative
> language on the list as an alternative to the imperative or hybrid
> languages, as it allows the use of three declarative programming
> paradigms (logic, functional and the declarative sub-variant of
> object-oriented) and, unlike most purely, declarative languages, it
> has a bit of uptake in the industry and outside of the academic
> world; of course other languages can be chosen. It may make sense to
> standardize the use of the same interpreted programming languages and
> intermediate representation language for the software running on the
> edge-servers as for that running on the clients as it would ease the
> development process. Big companies may use remote-servers, edge-
> servers (one per site) and on-site clients as an alternative to
> networked desktop computers, or they can let telecomuters use their
> own client and associated edge-server, to connect to the company
> remote-server to work on it, this approach of edge-server and client
> has the potential to replace part of the desktop market. As a last
> point, the case of DRM. DRM is fundamentally wrong and constitutes a
> stupid and useless idea, however, if the copyright industry is going
> to force it on a platform somewhere, it should rather be on this
> platform than elsewhere, it should definitively not be allowed on the
> other platform described previously (the one for hyperlinked,
> structured and semantically encoded documents), where openness is
> paramount. While trying to protect the "intellectual property" of the
> copyright industry, when implemented on user-owned client devices,
> DRM violates the physical property rights of the user. Client devices
> can come in two forms, user-owned and user-rented, when owned by the
> user, the user should be in control of the device, when user-rented,
> the owner renting-out the device defines the device-use limitations,
> having DRM on user-rented devices is a lesser evil. It could be
> decided that DRM on user-owned devices is prohibited while still
> allowing DRM on user-rented devices (the copyright industry would be
> free to make some content only available on rented devices if they
> really want to). While this is not a technical decision but a legal
> one, and as such, out of the scope of the people reading this, the
> various entities involved with the process can make it their official
> position that DRM on user-owned devices should be prohibited and, as
> such, help push for this legal concept. A broader deployment of
> rented client devices would probably resonate well with the public in
> this day and age. This is the time of XYZ-as-a-service all over the
> place, so having "services access as a service" would be bringing the
> concept to its ultimate level.
>
> May XML live-on till the end of times.
>
> Raphaël Hendricks
>
>
>
>
>