W3C home > Mailing lists > Public > www-style@w3.org > November 2005

Re: Why Binding Scripting in Style Layer Conflates Semantics

From: Shelby Moore <shelby@coolpage.com>
Date: Fri, 25 Nov 2005 22:52:52 -0500 (EST)
Message-ID: <4943.203.168.9.135.1132977172.squirrel@webmail6.pair.com>
To: www-style@w3.org

The Key Question:

Why not bind semantic subclasses in the style markup layer?

select { bind SmartDataSelect.xml }

where class SmartDataSelect inherits semantics from select class.


The Answer:

Because of interoperability, semantic markup and style markup are not
supposed to require each other, i.e. they are orthogonal layers.  Let me
elaborate.

In (x)HTML (or in an XML schema which may or may not subclass xHTML, e.g.
XAML), then for the above style markup in The Question, the corresponding
semantic layer markup would be:

<select...>...</select>

So for any consumer of this semantic markup to be aware of (not obscured
from) the subclassed semantics class SmartDataClass, now requires itself
not only to have a CSS parser, but also a specialized CSS parser which
knows how to convert bindings in CSS to semantic markup equivalents.  In
other words, the consumer has to flatten those two (no longer orthogonal)
layers back to one semantic markup layer:

<select x:Class="SmartDataSelect"...>...</select>

So the consumer can not just parse XML, it must also parse CSS and in
special way.  For example, you force search engines to add special CSS
parsing to prevent semantic obscurity.  This is the _initial_ complexity
you add by conflating the layers.  But it gets much worse...

But how do we flatten two things that don't have analogs in every case? 
The CSS model does not flatten to the semantic markup model.  CSS has
cascade and selectors which have no exact (one-to-one mapping) analog in
XML (HTML, SGML, etc.).  I won't even try to give examples here, let your
imagination run wild for implications.  But it gets worse still...

So we build all these cool ontology languages which interopt with XML, but
they can't interopt with semantics defined in CSS layer.  Whoops! 
"Moz-tribe" scratches their heads...But it gets worse still...

So let's assume use "bandaids and duct tape in spagetti mode" to overcome
our injured ("never inconsistent") egos above, then we still have an
impossible wall to climb.

How the heck do we know which bindings in the style layer are intended to
be style and which are intended to be semantic extensions?  I hear
"Moz-tribe" thinking "all of them!", then we are back to obscurity of for
example treating data as "countries" when the <select...> knows nothing
about data type it selects.

Once you conflate, you enter that blackhole that shortens the lifespan of
the work you do.  It is one of those immutable laws of OO programming that
many programmers to this day refuse to respect (at their own peril).  I
hear the "Glaz-pack" thinking what Glazman wrote 3 years ago, that
modularity is not "pragmatical" (exact quote I swear).


The Solution

I will repeat what I wrote 3 years ago:

XSLT

But the antagonist argues "you still require a style layer".  Well yes,
but you don't conflate the final _OUTPUT_ markup (the markup that the
consumer interprets, presents, etc), the transformation is well defined by
the XSLT specification (you don't need to flatten things in ways not
normative and that have no defined mapping), you don't have consumers
rolling their own brittle (not defined) mappings from style to semantics,
etc...

... and in the important case of the World Wide SEMANTIC Web being the
consumer, the XSLT transformation is going to happen at the server, so the
consumer doesn't even need to perform the XSLT transformation, it has
already been done.

I could elaborate further in the future.  That is enough for now.

Could we get on the more interesting thought processes about "The Future
of CSS in Semantic Web?"?  Or do we have to stay mired whether orthogonal
layers are good or bad?


-- 

Kind Regards,
Shelby Moore
http://coolpage.com
Received on Saturday, 26 November 2005 03:53:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:41 GMT