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

[Raphaël Hendricks <rhendricks@netcmail.com>]

Dear Mr. Liam Quin here is finally the answer after a delay.

to all list-users: I am sorry for the delay, there have been many  
days where I was too weak to answer, since I am battling chronic  
fatigue syndrome, and have many days where I am non-functionnal;  
moreover, during the few days where I felt better, I had some  
pressing issues to handle until a week ago, then I felt bad from  
monday to thursday and since I felt better afterwards, I prepared the  
answers for the list on Friday, Saturday and Sunday.

>> You must have realized that the termination
>> of a significant part of the Semantic Web effort, and the switch to
>> HTML5/JSON/javascript and related technologies
> There has been no such termination and switch.
Yes and no, there was the time when W3C decided to let the XHTML2.0  
project die and when it decided that the future of the web would be  
based on HTML5 and the work of WHATWG. It could have kept HTML5 out  
of its doors and continued the work on XHTML2.0/XForms et al. Also,  
the semantic web effort, while still existing is in a moribound state  
compared to its glory days.



> As for a separate platform for distributing code, this sounds like  
Saas
> and PaaS. How would it differ?
It would be a specific variant of software-as-a-service. It would,  
however rid itself of the use of web technologies to implement the  
client-side part, which is the most common method; it would be a  
clean version of software-as-a-service free of its web baggage and  
standardized; the few cases where the client-side isn't implemented  
using a web interface do use proprietary technologies which are not  
platform independant (web-interfaces are pretty much the only  
platform-independant client-side technology for accessing software-as- 
a-service). The proposal would offer a programming based (free of  
markup / XML / HTML) standardized method to implement the client-side  
access to the server-supplied software-as-a-service which would be  
accessible on many different types of devices, including, but not  
limited to, the now-so-popular mobile devices (smartphones and  
tablets). Software-as-a-service in its current form is a half-baked  
technology which either relies, for its client-side code, on  
bastardizing the web or on non-standard proprietary technologies.  
Moreover, it lacks one capability which would be the big new feature  
of the second platform in the proposal, there is no standardized  
mechanism to push most of the processing load on an edge server.  
Software-as-a-service as it is currently run still uses the client /  
server model as opposed to the client / edge-server / remote-server  
which this platform would allow. Having a client-server model means  
either major latencies due to lots of roundtrips to the server or  
major client processing workload when putting the load on the client  
to reduce lantency. Having a client / edge-server / remote-server  
model allows the combination of both a light processing load on the  
client and a reasonably short latency.

As I have stated in a reply, to another message to the list, the  
people who are against XML/XPath and the semantic web (and who are  
pushing the HTML5 nonsense) are the very same people trying to turn  
the web into a remote software execution platform. If they are  
redirected to a new platform meant for remote software execution and  
the entities (which include most browser makers) and money behind  
them is also redirected to the remote software execution platform,  
then suddenly, there would be no more force behind the HTML5 effort  
and almost no one fighting against the switch to XML/XPath and the  
semantic web. If the people who want to turn the web into a remote  
software execution platform are given the opportunity to switch to a  
new platform better suited for remote software execution, with proper  
mechanisms to integrate edge-computing and supplying corporate  
requirements as standard from the beginning, including security  
mechanisms and, yuk!, copy-protection; they will hopefully do so and  
reap its benefits; the web environment will then be mostly free of  
XML/XPath and semantic web opponents, the switch to XML/XPath and the  
semantic web can then happen with little opposition. As already  
stated if a new remote software execution platform is to be created,  
it should be now, when edge-computing is to become important, so as  
to integrate it from the start, afterwards, the opportunity will be  
past. Of course, as I already stated, it is best to rid the reborn  
web of the old names (html, xhtml, http, etc.) to avoid raising false  
expectations, a new set of names would be best for the new technologies.

Raphaël Hendricks