RE: Style Matters - A class act

Hi Dave,

Dave said:
And what of literals from the stylesheet? Are they linked back
to the stylesheet, or since they are present in the output file,
they are not marked with the link?

Didier replies:
The goal is not to link any objects but the most significant ones. So, in
fact, the most significant ones are mostly elements and attributes. For
instance, a <date> element is a semantic object, something that an
interpreter can understand as a date. Also, certain attributes like for
instance xlink:type="extended" can bring some semantics like saying that
this element is a one to many link. If we take the latter construct as an
example, we can convert a one to many kind of link to a context menu. The
menu is made of a <div> element that is processed by a javascript to show or
hide its content. So, we created from a semantics object called a link a
group of objects consisting of a <div> element containing other HTML
elements + a javascript to add behavior to the construct. To relate that
<div> element and its associated script to an xlink:type="extended" object
is quite useful since we now know that this drop down context menu created
from script and HTML elements is in fact an Xlink extended semantic object
(at this level of semantics - it could also be related to an higher level of
semantics like for instance being related to a topic object). So, we do not
relate everything. A literal would be related only if this latter is not
marked up and that some semantics is in fact hidden in a textual form. A
general practice would be instead to relate elements and attributes that are
semantically significant or that was the object of a transformation. So to
speak, to say that an xlink object of type "extended" is being transformed
into a context menu and this latter is in fact made of script and HTML
elements. That a table of contents is related to a <ul> HTML object that
contains <li> elements. But the <table-of-contents> XML element is related
to its rendition object that is the result of a combination of <ul> and <li>
elements. this could also be as well a hierarchy of <div> elements
associated to a script adding behavior. Thus, we created a rendition object
for the <table-of-contents>, this rendition object is the assembly of
several objects: HTML elements, CSS properties, scripts. This whole set of
object makes the rendition object. We then keep a relationship between this
new object composed of script, css properties and HTML elements and the XML
element it is mapped to. Idem for an attribute or any other semantically
significant object. The semantics depends obviously on the type of
application and the type of rendition you are using.

So we relate the mapping between an XML object to the set of object used to
render the XML object. The new object we created by assembling scripts, CSS
properties and HTML elements is in fact a semantic object made visible to
the user and having a behavior. We created a view on our semantic object.
Thus, for instance, what the user sees on the screen are not HTML elements,
scripts and CSS properties but more a "table of contents". We simply relate
the whole construct to the original semantic object so that this whole
construct is not a big bunch of loosely coupled object without meaning but
more a table of content that has a certain look and feel and behavior. We
simply added dimensions to the semantic object. In our source, we mention
that this is a "table of content" object and that the table of content is
not the whole HTML document but a fragment of it. we made it clear which
part of the HTML document is the "table of contents" object.

You can also say that from a programming point of view (both functional and
procedural). The <table-of-content> element is at one level a function and
at the other one a procedure. At one level we only keep a functional point
of view saying only what we want. So, we stayed in a world of "what". You
said "what you want". When we apply an XSLT transformation sheet to the XML
document, we can create a procedure that may look like a visual basic or
Delphi program - On one hand we have the set of visual objects with their
default behavior and on the other hand the procedure or event handler
attached to these objects, the whole (visual objects + script) is a small
program a la VB, Delphi or Power builder. Thus, we are now living in the
"how" world. We say "how to render and how to react to user events". If you
relate your "How to" world to the "What" world, you then created a link
between each functional elements and the procedural construct used to
manipulate it. You created a bridge between two facets of your solution: the
functional and the procedural.


Cheers
Didier PH Martin
----------------------------------------------
Email: martind@xxxxxxxxxxxxx
Conferences: Web New York (http://www.mfweb.com)
Book to come soon: XML Pro published by Wrox Press
Products: http://www.netfolder.com


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list