Shelby's Final Position Paper on XBL

Only 3 (or 4) people emailed me privately expressing support and asking
that I continue in the XBL thread.  So this did not meet my 5 minimum test,
per my poll in "XBL Thread: who wants Shelby to stop posting?" thread.
However, no one emailed me saying they wanted me to stop.  So I assume only
Daniel and Eric want me to, per their posts in "130" thread.

Also I do not see much point in continuing lengthy debate, since I have
already proved to myself where I should focus my next round of implementation.

However, I felt that I owed the supporters a better final summary.  Thus
follows my position paper on this matter, which I will not be debating at
all.  Any responses to this thread will be ignored.  Also, I will not be
receiving mail from the list any more.

I am posting this as a thread, instead of on a separate web page, because I
do not want to maintain a web page on this matter.  However, any one has my
permission to display the contents of this post (below) on a web page if
they so desire.

<h1>Shelby's Final Position Paper on XBL</h1>

<h2>What Is Style?</h2>

<p>Seems to me that "style" in W3C context, is separation of "presentation"
from "markup".</p>

<p>One could argue that presentation is thus any thing which is not
markup.&nbsp; That would seem to be overly broad, because then there would
only be two working groups at W3C, style and markup.&nbsp; This would mean
for example that XEvents group should be merged under the style working
group, because events are not markup.&nbsp; Or that if XEvents is markup,
then it should be merged under markup group.</p>

<p>So what is presentation?&nbsp; I have argued that presentation is any
implementation of markup which creates semantics that are compliant with
markup specifications.&nbsp; Most (if not all) of CSS fulfills this
presentation test.&nbsp; And I have argued that any implementation of
markup, which creates semantics that are <b>not</b> compliant with markup
specifications, is thus not presentation.</p>

<p>So if ever there is a technology which enables implementation, which is
not presentation according to test above, then is it still style?&nbsp;
Perhaps it could be, if it is also separate from markup.&nbsp; It doesn't
seem to be the past or current pattern of W3C to merge every thing which is
not markup, into style.&nbsp; For example, XEvents (or some other W3C
technology) might be presentation under my test above, if we assume XEvents
is not markup, but that does not follow that it should be style.</p>

<h2>Is XBL Presentation?</h2>

<p>I argue that if XBL fails the presentation test above in important
scenarios, then it is <b>not</p> purely presentation.&nbsp; I also argue
that XBL has the capacity in some cases to completely replace the
implementation of new and existing tags (which for example CSS can not
do).&nbsp; When implementing such a tag with XBL, one has adequate freedom
to implement that tag to create semantics which are not compliant with
markup.&nbsp; Thus I argue that XBL fails the presentation test in some
cases for the important scenario of implementing tags.&nbsp; I argue that
it is up to the XBL supporters to prove beyond a reasonable doubt that XBL
can not do this, if they wish to argue that XBL is purely presentation.</p>

<p>Since I have argued that XBL is not purely presentation, then it follows
from my other arguments above, that XBL does not reasonably belong in the
style group at W3C.</p>

<h2>Is XBL Markup?</h2>

<p>Since I have argued above that XBL has some capacity to create
non-compliant semantics (i.e. is also not presentation), then it follows
that XBL has capacity to define new markup.&nsbp; This markup may not (or
may) be compliant with some centralized markup specification, such as W3C
HTML, yet it still has the capacity to define markup.</p>

<p>However, we usually think of markup as centralized specifications, so in
that sense XBL is not purely markup either.&nbsp; I could into more detail
into my analysis of what XBL is, but it would be controversial, because I
would go into abstract ideas about orthogonal layers, and the benefits of
keeping for example events (XEvents) separate from both markup and
presentation.&nbsp; And then I would make some arguments about how XBL
seems to instead merge these layers.</p>

<h2>Better Way?</h2>

<p>I merely observed that XSLT has capacity to replace existing and new
tags with other markup.&nsbp; XSLT transforms markup into other markup, and
can also combine into the transformation other orthogonal layers such as
XEvents.&nbsp; Thus although XSLT can create non-compliant semantics of
it's input document, the markup portion of its output document is always as
compliant as non-transformed markup.&nbsp; This is because the output
markup portion is not obscured (not anonymous) and is not further replaced.</p>

<p>Thus follows my conclusion that keeping semantic transformations in the
markup layer is the most W3C compliant mechanism.</p>

<p>And on a practical note, XSLT 1.0 is fully supported in Internet
Explorer 6, while XBL is only supported in Netscape (Mozilla).&nbsp; My
data shows that Internet Explorer is available on greater than 90% of

-Shelby Moore

Received on Monday, 6 January 2003 08:52:22 UTC