Re: Why Binding Scripting in Style Layer Conflates Semantics

Thanks for breath of fresh air.  Agree with your summary, except...

Yuh-Ruey Chen wrote:
> (3) He wants all "semantic data" to be in the "markup layer" and not at all
> in the "style layer", and all "style data" to only be in the "style layer".


Correct and remember I made the point that styles embedded in markup are
still in style layer.  Physical location is not the factor in conflation. 
It's the architecture of binding.


> (4) Others point out that what he defines as the "style layer" is not
accurate. From a theoretical standpoint, CSS selectors are unrelated to
style. CSS selectors can add other things beside style, and adding style
does not require CSS selectors. For example, CSS selectors could be used
like XPath, and XPath could be used to add style (if not for performance
issues).


But it is not just that, it is the styles (color, font, display, etc) are
intermixed within the inheritance model.  There is no mapping back to the
semantic layer.  You can't just extract the binding, it is all interwoven.


> (5) Shelby replies that if semantic data is added via CSS, then all UAs
would have to understand CSS selectors, including search engine robots
and other semantic data miners. He also has another reason he is against
this -
> see (8).


Not just understanding it, but it is not a one-to-one mapping back to the
semantic layer.  There is no defined mapping.  It is a heuristic
proposition.  And that is a _key_ point.


> (9) XBL supporters also say that XSLT also has its shortcomings. While
XBL could be misused to add content (XBL adding an advertisement above
an input
> element), XSLT could be misused to distort content (XSLT outputting
nested HTML tables).


Both can do lots of things, but the key is that XSLT can not hide it's
changes from the "markup layer".  You said that in other numbered point,
but I just want to make it clear that it what XSLT can do is irrelevant to
whether semantics are hidden or not, which can not be said for XBL.


> (13) Since UAs would need to understand XAML, he is depending on XAML
and .NET becoming widely accepted and available standards. He also
> acknowledges
> that there must be some way to distribute .NET classes.


Or XUL or anything at "markup layer"... but not XBL in CSS.



> (14) Shelby and others disagree on what semantics "include". An example
is thrown about involving a select-country widget. Some argue that how
this widget is displayed and interacted with has nothing to do with
semantics. Shelby agrees that how its displayed doesn't matter, but how
it is interacted with involves semantics. I believe this is what he
means when he
> says "semantic presentation".


IMPORTANT: I am not distinguishing what aspect modifies semantics
(display, interaction, duration, persistance, etc).  It will vary in every
case of a tag.  As TBL wrote, the "abstract content" (the meaning of the
tag) defines it's semantics.  If the presentation changes OR subclasses
that abstract meaning, then semantics have been extended.


> - I find this whole thing really analogous to the pros and cons of
aspect-oriented programming. XAML sounds like very traditional
> object-oriented programming. XBL follows aspect-oriented programming, where
> the XBL document is the aspect, the selector (either CSS selector or the
XBL
> element attribute) is the pointcut, and the document is the program the
aspect is being applied to. So take everything that's been debated about
AOP, and dump it here.


Except that we are not comparing AOP and OO at the same layer.  The AOP in
the style layer is my complaint.  Move the AOP to the markup layer, then
it is fine with me, just an alternative means of wiring OO.  For me,
"many-to-many" event model are essentially AOP, and I use that extensively
in the internal programming of new Cool Page.  I am not against the
paradigm, just the layer conflation.

> - I personally like XBL. I haven't played around with it yet but I've
read the spec. I'm not against AOP and I like the binding flexibility of
XBL. As
> a fan of JavaScript/ECMAScript and Python, both of which are very
flexible languages, this should come as no surprise.


I urge you to consider that the language paradigms you like have little
(nothing?) to do with conflation of layers.  I also find Javascript useful
for certain tasks, as well Perl/PHP and as I said a "many-to-many" event
model for OO interaction.

Thanks again for your open-minded post.


-- 

Kind Regards,
Shelby Moore
http://coolpage.com




-- 

Kind Regards,
Shelby Moore
http://coolpage.com

Received on Saturday, 26 November 2005 16:30:44 UTC