Re: Why Binding Scripting in Style Layer Conflates Semantics

 Hello, this is my first post in this mailing list. I've read most of this
discussion and know a bit about XBL and XForms, so I'll put in a couple
words if you all won't mind :)

Shelby has some interesting points, but they're spread across to too many
words. I'm not sure if I get everything myself, so let me try summarizing
arguments, both to and fro:

(1) New types of data and input widgets are a good thing. Everyone agrees on
this.

(2) He differentiates between "style markup" (or "style layer") and
"semantic markup" (or simply "markup layer"). That translates to "CSS" and
"HTML/XML markup" respectively.

(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".
This is what he means when he says "the style layer is orthogonal to the
markup layer". On a certain level, everyone agrees with this (presentation
is separate from content).

(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).

(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).

(6) He also considers any added markup to add to the semantics of the
document, and that those semantics be accessible by any UA. This is why he
is one reason he is against XBL, which can add markup but would essentially
be invisible to non-presentational UAs (it would require those UAs to
understand XBL), and is for XSLT, which "adds" markup that is visible to all
UAs (those UAs do not have to understand XSLT).

(7) XBL supporters counter that when properly used, XBL will not introduce
any semantics.

(8) Shelby points out that XBL could add functionality to existing
"elements" (an element/attribute combination that has existing
functionality, e.g. a plain <select>) without requiring custom attributes to
differentiate between the original "element" and the new one. He considers
this flexibility a bad thing. To elaborate, he doesn't want the semantics of
existing "elements" to be changed, or rather the ability to apply such
changes. This is the other reason he dislikes XBL and using CSS selectors
for binding semantic data.

(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).

(10) XSLT could technically be applied client-side as well. It would be
similar to applying XBL, the main difference being that whatever was added
by XBL will be "hidden" while everything in XSLT wouldn't be. As far as I
can tell, Shelby would be okay with client-side XSLT if not for the fact
that UAs would need to support it.

(12) Shelby acknowledges that XSLT is only a "bridge mechanism" and
advocates XAML's class-binding mechanism as the best way to add new types of
data and input widgets. Specifically, XAML allows new functionality only in
new "elements" - existing elements can opt out by not specifying the Class
attribute. For this reason, this feature is also backwards compatible. I'm
not sure on the specifics, but apparently XAML also has a nice sub-classing
feature to it.

(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.

(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".

(15) XForms is mentioned as a better alternative to binding classes directly
to input elements with XAML's Class attribute (and it's a W3C spec to boot).
Shelby apparently has no issues with XForms and wants to know where XAML and
XForms overlap.

Okay, so that was a lot of words. Only goes to show how complicated this
whole thing is.

My own points:

- 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.

- Terminology is being thrown around crazily without any consensus between
both sides. Even worse, when some new term enters the arena, it only
distracts from the main points. Please, try to keep to simple words that
everyone can agree to. Or make it very very clear what definition you're
using (and please don't try to argue that your definition is the correct
one).

- 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.

- W3C has shown interest in standardizing an application specification
language such as XAML and XUL. They've just created the
public-appformats@w3.org mailing list, so if you're interested in this, you
should discuss XAML and related stuff there. I'm actually doubtful any
consensus will be reached there, considering how established and different
both XUL and XAML are, but only time will tell.

- I also like XForms. Although it's not backwards compatible, it's a very
nice spec to base intranet applications on. I consider it superior to what I
know of XAML in the areas that they overlap. Separating form data (and
datatypes) from content is very elegant.

That's my 2 cents.

- Maian