RE: Hlink, CSS anyone?

Hi Eric,

[Eric proposal to explore using CSS for Hlink to xlink mapping...]

Didier replies:
Ok this is a working hypothesis and this avenue needs to more explored.

Here is another one:
Premises:
----------
a) browsers support XSLT 1.0 (actually, Mozilla and IE, probably Opera
in a near future - Small devices browsers like mobile phones do not
support it, only XHTML 1.0 + CSS.
b) XHTML 2.0 proposes more semantic elements and less rendition
elements.
c) most of the browsers support a DHMTL visual model. In fact HTML or
XHTML is used to encode a hierarchy of visual objects. There is a one to
one equivalency of most of the HTML (or XHTML 1.0) elements and a visual
element (with the exception of some non visual elements)

Proposal:
---------
Since, XSLT transformations are possible either on the server side or on
the client side and since the number of XSLT enabled browsers is
growing, then a clear separation of the rendering and the semantics is
made more and more possible.

To encourage this view/model pattern, XHTML may evolve toward being a
language with more semantics. IN fact XHTML 2.0 shown some sign that
this is the case. 

An XHTML document could be transformed for rendition with an XSLT style
sheet or with a CSS style sheet. This transformation establish a one to
one mapping of certain elements/attributes into visual objects.

However, with the actual state of the arts, it is very difficult to
encode images as semantics, probably at the meta level but hardly at
other levels. Thus, there is a very high probability that visual object
such as SVG or MathML objects are to be embedded into XHTML documents.
Two choices are offered
a) the visual objects are defined into the XHTML document
b) the visual objects are external to the document and referred with a
link.

In case (1): the visual object is embedded into the XHTML document. The
XHTML document can be made more coherent and logically consistent if all
links are expressed in the same way. For instance, that an SVG, mathML
or XHTML links share the same characteristics and syntax. An <a> element
in SVG is also identical in XHTML and if both share the same
characteristics, then the overall document is more readable,
understandable, easier to maintain. It has been proven in software
psychology - mainly through the work of Ben Shneiderman (1) -  that
coherence is an important factor to reduce errors, reduce the learning
curve. Moreover, coherency may cause a network factor and induce other
domain language authors to follow the recipe.

In case (2): the visual object is external and referred with a link. If
XHTML takes the path of having a single element for anything to be
embedded in the final rendition (i.e. the <object> element). Then this
object could be expressed as an xlink extended. This may require an
upgrade of the xlink specs. However, this update shouldn't break the
other language using xlink 1.0 already. We are fortunate that these
modification are possible without causing a breakdown to other domain
languages using Xlink 1.0 (by using some defaults premises like arc
direction, etc.).

In a previous post, it has been shown that new possibilities are brought
if XHTML uses xlink. In previous post, we also notices that Xlink needs
some specs upgrades. The capacity to use an <a> element (as a simple
link) or to overload it to be an xlink extended element brings something
more.

Up to now, it has not been proved that not using xlink or using Hlink
brings new capabilities to XHTML. To the contrary, it just add more
processing or more information to add to an XHTML document. Moreover, it
causes a major breakdown for an XHTML document to be processed on the
client side with an XSLT style sheet. It does not reduce the complexity
nor it brings us more than we have today. Just more constraints and
potential added costs.

Cheers
Didier PH Martin

Received on Saturday, 28 September 2002 10:54:50 UTC