The Web (noted www for World Wide Web) is the system constituted by links between hypertext documents, what reminds the shape of a spider's work. These documents are text files respecting the HyperText Markup Language (HTML). These files are exchanged using the HyperText Transfer Protocol (HTTP). A simple Web transaction occurs between a Web server (e.g Apache HTTP server, Apache Tomcat, IIS) and a computer workstation where it is visualized by a human user in a Web brower (e.g. Internet Explorer, Mozilla Firefox, Apple Safari, Google Chrome).
The idea was initially
proposed
by Sir Tim Berners-Lee
and
Robert Cailliau
in 1990 at the CERN. The Web currently evolves in the frame of an international group: the World Wide Web Consortium (W3C). This group produces recommendations which act as standards to be respected by Web browsers.
In 2001,
an article
by Berners-Lee et al. introduced the idea of the Semantic Web. That idea would simplify internationalization issues and allow inference what could possibly induce logical deduction using prositional calculus. These topics have still to be developed to become concrete. The Resource Description Framework (RDF) is a standard model for pure semantic documents. The Microdata W3C recommendation allows the integration of semantic relationships in HTML documents.
In 2004,
the W3C
described the
Architecture of the World Wide Web, Volume One.
That document insists on the importance of resources identification with URIs. By the way, hypertext links are confirmed in their composition of the Web because of resources references.
The Representational State Transfer (ReST) architectural style defined by Roy Fielding as a client-server model taking advantage of hyperlinks
It seems at the end of that period rich client applications are on the decline and RIAs are let aside. The ReST architectural style is arguably claimed by many systems. However, the initial architecture taking advantage of hyperlinks is largely used, what simplifies the rendering by Web browsers and the crawling by search engines.
Material Jekyll is a set of Polymer components helping to set up a Jekyll template. Few modifications where needed, one was pushed to the initial repository as it could be useful to other users: colors customization with a single Jekyll data file.
Following my previous post, I tried to play with Polymer on my spare time. In my mind, Web components could be an important point for the architecture of the Web. On one side the Web would be easier to handle for automated systems because of the separation of information and presentation. On the other side Web applications would become easier to design for the same reason.
Software modeling is interesting because it provides a graphical representation of software. As a consequence, UML is an expressive representation for design and documentation. The Eclipse UML2 project relies on an XML file which tends to become a standard form for the persistence of UML models. In that XML file all the informations relative to an UML model are available.
In the discovery of the Polymer platform came the idea of Polymeria: bridging the gap between the XML representation of an UML model and its graphical representation. The principle sounds simple: writing a Web component for each UML element. This is an echo to the idea exposed by E. Bidelman that every framework is compatible with
DOM (further information is available in my previous post).
First constraint: Web component namesmust contain a dash in order to avoid overriding standard HTML element names. The problem is that Eclipse UML2 XML element names do not necessarily contain a dash. In other words, the XML file needs a transformation.
The main issue comes with the Web component for an UML attribute: the XML tag generated by most UML2 tools is self-closing. The behavior is quite surprising in some cases, some side-effects are completely unexpected. For example, some classes appear in a wrong package. I open an issue in the Polymer project because the self-closing tag renders in a surprising way. And it appears one and two others had been submitted before. Self-closing tags are not allowed in Web components.
Every framework is compatible with DOM. But DOM is not necessarily compatible with Web components. After these two limitations, it seems Web components are perhaps XML compliant. However an XML model is tricky to adapt as a Web components document. The random support of self-closing tags can be rather disappointing for a first contact with Web components...
Here is an HTML sample of Polymeria showing the transformations needed and the Web components obtained (a proper rendering has been tested with Chrome and Firefox).
At
Google I/O 2014,
Polymer
was introduced in deep
by
EricBidelman.
Polymer
is a very interesting move by
Google</meta>
</meta>
promoting in some way a W3C work:
Web components.
I try to sum up here all I learned from the Polymer tutorial.
What is the relationship between Web components (as a W3C recommendation) and the Polymer project (as lead by Google) ? In a few words, Polymer bridges the gap between the work pending in the frame of the recommendation working group and the features implemented by browsers. This is done via a simple Javascript, platform.js. The Polymer project also provides a set of initial web components to simplify the development of web-component-based applications.
Web components are custom HTML tags. How is the behavior and rendering of such elements defined ?
The components definition relies by convenience on another W3C recommendation,
HTML imports.
Introduced as a new link type (import) the principle is simple. This allows to include an external resource into an HTML resource. The practice for Web components is to use an included resource defining the behavior of each custom element in order to allow reuse of that definition. Web components could of course be defined without imports but this would be of limited interest. A singularity about HTML imports is detailed in a
blog post
by
TJ
Van Toll:
defining multiple imports using a same library (e.g. jQuery) can be challenging to load for browsers. Strategies have to be found to reduce loadings.
One important point is in the naming of custom element. As explained in
that article
by
ZenoRocha,
each name should contain a dash in order to avoid conflicts with standard HTML elements (which are still important because needed in the definition of custom elements).
In the introduction, Bidelman</meta> states that every framework is compatible with
DOM
.
Indeed, as a result of the document structure simplification induced by Web components, this is a huge change in the way information is provided on the Web. This won't change so much for end users in the first place.
On a software engineering point of view, the step could be a real revolution: information provided by the Web server could have a same structure for a Web browser and for any software client. HTML would really look like an XML document, except for the head imports.
What will make the real success of Web components is the behavior of software giants. And with Polymer, Google seems to be seriously involved. Could it be a serious move to use Web standards in replacement of any Android API challenged by the Oracle lawsuit ? Perhaps the end of the mobile native / Web apps dichotomy ? Is it a dream ? Still a long way to go for involved engineers, but so many promises...
Edit(2014-12-26): the platform.js script has becomewebcomponents.js.