Re: XBL is (mostly) W3C redundant, and CSS is wrong W3C layer for semantic behavior *markup*

At 06:28 AM 12/31/2002 +0000, Ian Hickson wrote:

[...]


>>>
>>> No offense but that _completely_ misses the point.
>> 
>> Which point is that exactly?
>
>The challenge was to use XSLT to take a combination of elements in a
>source document and provide the user with dynamic behaviour such as
>typically expected of a <select> element.


It is a loosing argument to hinge your support of XBL on the fact that it
has "handler" in it's syntax.  "handler" is easily implemented as a XSLT
transformation by numerous other ways of doing events, e.g. XEvents.  See
my responses to David Baron today.

*IF* your objective is to keep restating the challenge in hopes that you
can "filibuster" or win by attrition, then I will let you have the last
word.  More likely, we just have different basis of understanding, and this
is becoming less productive than just waiting for me produce compelling
examples when it fits my business objectives.



>What you did is use a document-wide transformation to convert one
>element into another, without providing any dynamic behaviour,
>styling, DOM-level functionality, form submission support, or session
>history support.


One can put any kind of content in the transformation output.  Certainly
style, DOM interfaces, and forms are accessible thru content standards (DOM
HTML, DOM CSS, etc.).



>The point was that XBL allows this to be done easily while XSLT does
>not.


Note the word "easily".  And previously you used "neat".   I will not
debate personal preference, because it can't be objectively debated.


[...]

>> You have done a good job in presenting a complex enough example,
>> that I do not have time to implement it right this minute.
>
>Very well, let me present you with a much simpler one.
>
>Given a document:
>
>   <?xml-stylesheet href="example" ?>
>   <root/>
>
>...give me the XSLT stylesheet "example" which would cause any
>children added to this element using DOM access


XSLT can output content which interacts with DOM.  XSLT can not itself
interact with the DOM, which is MAJOR advantage of XSLT for reasons of
proper orthogonal design.



> to be given a child
>text node with the text "Child", followed by the value of the
>element's "number" attribute, followed by the text ": ", and a DOM
>method that, when invoked, appends the text passed as the argument to
>this text.


What is the compelling use of such an example?

Doesn't this example basically prove that XBL is non-orthogonal to the DOM,
which I have already argued is bad design.  You can disagree with me that
orthogonality of DOM and XBL is important.  I won't debate your opinion.
Personal preference for correct design can't be debated, except in the end
result a few years from now.

I do not really see the point of taking the time to analyze something for
which it seems has no practical use and for which seems to favor
characteristics of XBL which I think are a major flaw in design.


>
>Fair's fair, so I wrote the CSS+XBL equivalent:
>
>   CSS: http://www.hixie.ch/tests/adhoc/xbl/demos/simple-stylesheet.css
>   XBL: http://www.hixie.ch/tests/adhoc/xbl/demos/simple-xbl.xml


I have not studied it.  Your description of it's function does not inspire
me.  I think my example to convert <select> to radio buttons was more
inspiring.  I could and will present more compelling examples later with
interactive events.  I'll let the readers decide.  My purpose was only to
come here and present data for W3C to consider.  Some people may find my
logic to be useful and correct for their purposes.

You've apparently proved that XBL is good at making inseparable
dependencies between CSS, DOM, events, and XBL.


>I made a test driver app in HTML to test it:
>
>   HTML: http://www.hixie.ch/tests/adhoc/xbl/demos/simple-driver.html



I get an error when running Internet Explorer.  Unable to test.

Line13: "undefined" is null or not an object


>Could you show me the XSLT which would replace the CSS and XBL given
>above to get the same effect without changing the HTML file? (There is
>_absolutely nothing_ XBL-specific in the HTML file.)



Wait a couple of (maybe few) months, then I will post some compelling
complex examples.  I assume the timeline for XBL standards consideration
can tolerate a few months for competing examples.  If not, oh well...


>My apologies, it was certainly not my intent to offend or be obscene.
>Brainfuck is the name of the programming language, there isn't much I
>can do about that.


And !@*%#$%^ is in the dictionary.



>My point stands, though: that a language is turing complete does not
>imply anything about its abilities in terms of the surrounding
>environment.
>A better example than brainfuck is a Turing Machine. A Turing Machine
>is Turing Complete, but it has no way to play music on a sound card,
>since the Turing Machine specification doesn't include an API for a
>sound device of any kind.



XSLT outputs XML and CDATA.  That is about as general as you need to do any
W3 content.


>>> Turing complete does _not_ mean it can do anything -- XSLT cannot, for
>>> instance, add a new DOM interface to an element.
>> 
>> Of course it can.
>
>How?


Afaik, using Javascript.



>A thorough examination of the XSLT spec uncovered only two occurances
>of the term DOM, and neither had anything to do with extending the DOM
>to add custom methods or properties.
>
>Did I miss something?


*THAT* is the point.  XSLT is orthogonal to DOM.  It doesn't need to
mention DOM or any other layer.  But you can output transformed content and
scripting which interacts with DOM.

When something is orthogonal, it doesn't try to predict it's external
utility.  That is definition of "black box".  This is how we maximize
utility over the long run.  People such as I, who have written huge
projects with multiple year life spans, know something about the importance
of OO design.  Non-orthogonal designs get brittle over time.  Then you have
to start over again.



>> Making extensions to DOM to accomplish binding is silly
>> non-orthogonal design.
>
>Non-orthogonal to what?


DOM non-orthogonal to binding.



>Behaviour bindings are, by their very nature, a combination of styling
>and dynamic DOM manipulation.


That is one nature of behavior, but not all possibilities.  You can have
behavior without DOM or CSS.

More importantly, the highest layer is binding of semantic markup to
swappable implementation (anonymous content).  The next layer below that is
DOM.  The next layer below that is style and events.

XBL merges all the layers.  XSLT does not force, although it could be used
to.  A well (proper OO design) coded XSLT binding will be more flexible now
and in future.  XBL encourages dependencies that are better left orthogonal.



>>>   2. The times next to the posts on http://ln.hixie.ch/ are, in the
>>>      markup, served as times in UTC. Using XBL [3], the times are
>>>      displayed in the local time zone.
>>>
>>>      Can you do this is XSLT at all?
>> 
>> 
>> Of course this is very easy.  You would just enclose the time content in
>> custom tag of name yuo choose such as <timezone>2002-12-27 23:21 
>UTC</timezone>
>
>Without changing my originial markup [1], how would you do it?


Now you change the challenge again.  Why is it important I not be able to
use a tag to semantic identify where the time data is?  I think the
opposite.  It is desireable to semantically markup the time.  Imo that is
the whole point of semantic binding...



>I would be very interested in seeing the actual XSLT you would use to
>do this. My thorough examination of the XSLT spec did not find any
>date or time manipulation routines.


Why do you want time or date functions in a binding layer??

Those are totally different things.  You would advocate merging time and
date libraries into binding layers??

Imo I am for orthogonal (Object Oriented) design, not procedural "spagetti"
code.


>> And then your page would run on ALL browsers. I can't believe that
>> you would make your web page only run properly on Mozilla with it's
>> miniscule usage. I guess you only expect visitors from your Mozilla
>> friends. It is a small world after all.
>
>The binding is not essential to the page -- which is why it is bound
>from the CSS level.


Non-compelling use example then?



>> But XBL is not orthogonal to DOM and CSS as explained in previous posts.
>
>Indeed. XBL is a glue language to combine DOM and CSS together for
>behavioural styling.


Now we agree.  :-)

Except XBL also does semantic binding.  That is where it crosses into a
terrrority that should be left for an orthogonal layer.


>It is not the only language developed for this purpose -- Microsoft
>developed HTCs several years ago; Netscape developed ActionSheets
>(although those were never implemented).


And I will probably (haven't studied them) argue against all for the same
reasons given here.


>
>XBL and HTCs are actually very similar at a superficial level,
>although IMHO XBL integrates the W3C technologies in a better fashion.
>(It was invented after HTCs, and learnt a great deal from the
>experience the Web had with HTCs.)


And my prediction is you will be learning from XBL and have to start all
over again.  Because of fundamental flaw at the core orthogonalities.  It
is a very important paradigm to master.



>>> Behaviours are not semantic --
>>  
>> EXACTLY!  That is why you don't want to merge binding and behaviors. 
>
>What do you think is the difference between bindings and behaviours?


Please see what I wrote above about the layers of design.


>> You are not locked into a non-orthogonal merged mix.
>
>I haven't the first idea of what you mean by this.


I do not know how else to explain that if handler is in the syntax of XBL,
then you won't be easily adapting your XBL code for XEvents or any other
superior standard that comes along.  And remember when XBL needs to be
improved, you have to wait for all UA to upgrade.

Whereas with XSLT, you just change a transformation.  You don't have to
wait on XBL version 2.  You don't have to wait on browsers.  If you want to
try out XEvents, or any other technology, then you can, because the
semantic binding is orthogonal to all the other layers of implementation.


>
>
>> You are thinking non-orthogonally. 
>
>Why thank you. I do believe that is one of the nicest compliments I've
>been given recently.

Apologies I did not mean it as an insult.  I meant it as (my assumption of)
the explanation for the basis of your logic.  Until we get the same basis,
we might as well be speaking two different untranslated languages.

-Shelby Moore

Received on Tuesday, 31 December 2002 03:00:55 UTC