What are the implications of the concept of the document tree?

The concept of document tree is enforced in XML files. Most of the times, it can also be correctly extracted from HTML files, where it is usually accessed and manipulated via JavaScript using the Document Object Model (DOM) API. The term ‘document tree’ is usually used in the context of XML files, while the DOM is associated mostly with HTML files – although the two terms can, and are sometimes used interchangeably.

In the context of XML files, the concept of the document tree is crucial to a number of aspects. First of all, every XML file contains ( or can be considered as being ) a document tree – with the root element as the root of the document tree, and each subsequent element forming a branch. The last element on a branch is called a ‘leaf’.

One of the implications concerns XML parsers and accessing API’s – due to it’s tree structure, XML documents are commonly parsed and stored into memory as a tree data structure, with each node representing an element. The DOM is the most common convention for representing and interacting with XML documents.

The document tree is also relied on by XPath – which is used to address parts of an XML document. XPath uses a path notation ( hence the name ) similar to URL notations to navigate through the hierarchical structure of an XML document – the document tree.

What are the relative merits of CSS and XSL?

Certainly, there is overlap between CSS and XSL functionality, since both these technologies are often employed to describe how (X)HTML is to be displayed. Both CSS and XSL can also be used to style XML documents in general – for example, SVG images.

But they also differ in some aspects, one of the salient differences stems from their intended scope – CSS was designed from the outset as styling language to be used for HTML documents, while XSL was designed to style and transform XML documents.
This resulted in the two technologies having significant differences:

-         CSS is terser, while XSL is verbose.

-         CSS keeps contents separated from presentation.

-         XLS is more intuitive – becoming proficient at styling and layout with CSS is not easy and takes a long time, and debugging layout issues is notoriously difficult for users with limited experience. XLS provides a more direct and explicit route to the desired outcome.

-         XLS has, arguably, better browser support – XSL version 1.0, which contains enough functionality to ensure an adequate level of customization, is supported by all major browsers

-         XSL has less cross-browser issues

What is the current status of XSL?

XSL was developed initially as a specification for defining how an XML document is to be displayed. Over the course of it’s evolution, it split into three components: XSL Transformation ( XSLT ), XSL Formatting Objects ( XFO ), and the XML Path ( XPath ). XPath, unlike XSLT and XFO, does not have an XML syntax; it is used to specify parts of an XML document.

Much like CSS3 modules, the different components of XSL can have different a status and version, although XPath and XSLT usually have the same version because they are developed in tandem  . Support for XSL technologies varies with browsers and applications, but overall browsers have good support for XSL, for quite a long time; Internet Explorer 5 supported the XSLT1.0 draft specification since 1999, although the final recommendation was different from the draft.

Currently, all major browsers fully implement the XSLT1.0 specification. However, even though XSLT 2.0 reached the W3C Recommendation status in 2007, support for it remains rare in browsers, and XSLT 1.0 remains in widespread usage.

What is the current status of CSS?

According to W3C, currently the latest finalized standard is CSS2.1 – which became a W3C Recommendation on the 7^th of July 2011. CSS2.1 was developed after numerous flaws were found in CSS2, and some features were not implemented by browsers. CSS2 is currently not maintained (http://www.w3.org/TR/2008/REC-CSS2-20080411/), and W3C points authors and implementors to the CSS2.1 specification, effectively admitting that CSS2 is obsolete. CSS2.1 also includes some features initially scheduled for CSS3, but it is mainly a “snapshot” of CSS usage at the time it was published (http://www.w3.org/TR/CSS2/), encompassing features that were widely implemented by browsers at the time the recommendation was published.

CSS2.1, therefore, was a temporary, transitional solution, to easy the pain of web developers at the time and provide guidance for browser implementors. Work on CSS3 has begun around the time the CSS2 recommendation was published. But, unlike CSS2, the CSS level 3 is not a monolithic specification; instead, requirements are classified into modules, and each module can have a different priority for W3C, and level of implementation by browsers.

For example, Level 3 CSS Backgrounds and Borders is currently classified as having “High Priority”, and is a Candidate Requirement – which means it was widely reviewed, and satisfies W3C’s technical requirements (http://www.w3.org/2005/10/Process-20051014/tr#q73); if implementation experience is deemed satisfactory, it will gain a Proposed Recommendation status. Currently, there is no document describing the CSS3 standard, but separate documents are available for each module. For example, the document for Level 3 CSS Backgrounds and Borders can be found here: http://www.w3.org/TR/css3-background/.

Browser can have different levels of support for different CSS Level 3 modules; browser implementors are encouraged to define compatibility with Level 3 on a per-module basis, instead of individual features, or CSS 3 as a whole. Browser implementors are more likely to concentrate on implementing modules, than individual features.