- From: Shelby Moore <shelby@coolpage.com>
- Date: Tue, 31 Dec 2002 21:22:48 -0600
- To: Ian Hickson <ian@hixie.ch>
- Cc: www-style@w3.org
Ian,
...this continues my response in 2 parts...
>One of XBL's other strengths is that it can be introduced at the user
>stylesheet level, where it affects every document the user reads.
Not until UAs implement XBL.
XSLT can also be swappable if UAs chose to.
No advantage to either so far...
...however the potential advantage of XSLT swapping, is that the semantic
swapping could be orthogonal (separable) from the style swapping.
>> The "meaning" of a <select> is to be able to select from a list.
>
>Exactly. What it does not say, is how to present the list; how the
>list should react to clicks, how ctrl + left-arrow should affect the
>selection, etc.
>
>This is what XBL is designed to do.
You deleted my main point. You were saying that my <select> example did
not implement swappable behavior. You said it changed the semantics. And I
responded that radio buttons are another way to implement selection from
lists. My simple example was canonical.
>>>>>>> Turing complete does _not_ mean it can do anything -- XSLT
>>>>>>> cannot, for instance, add a new DOM interface to an element.
>> [...]
>>
>> Javascript can add new properties and methods to existing objects. I
>> am confident you know the syntax.
>
>I didn't ask how you added properties and methods to existing objects.
>I asked about adding new DOM interfaces to a DOM Element.
>
>The difference is what happens in cross-language environments, and
>what happens to objects that are garbage collected.
>
>e.g.: take an object wrapped around an Element interface. Add a new
>method.
>
>That method is not accessible outside JS (e.g. from VBScript or
>PerlScript).
That is a problem of Javascript. SOAP or other technologies might solve in
future. It is an orthogonal design problem which should not be merged into
semantic binding layer.
>Now let the object go out of scope, and get an object wrapping the
>same Element interface.
>
>The method will have disappeared.
You are trying to create extensible *standard* DOM interfaces without those
interfaces being *standards*. It does not good for them to be persistant
if the other layers have no idea what to do with them. If you write other
layers to rely on non-standard interfaces, then you merge even more layers
and everything gets even more brittle. That is the WHOLE point of the
W3C!!!! I refer you back to what I wrote in previous part of response:
-----
You are trying solve the problem of semantic standards by changing what
semantics is. Semantics is "consistent meaning" else it loses utility as a
layer.
Instead if you want certain custom tags to be a standard in DOM, then do
that. You will never provide infinite cases, but destroying consistent
semantic layer just so you can get custom tags in the DOM which mean
nothing to other layers (because they aren't standard custom tags), only
accomplishes reducing the utility of what semantic layer is for.
Not to mention how brittle every thing will get.
-----
And:
------
I only see that semantic layer is best left orthogonal. If DOM extensions
are needed they can be done with tranditional standards efforts such as DOM
HTML, DOM XHTML, DOM CSS. Will there be a DOM XSL-FO?? Etc..
------
> (Actually there is typicially as
>race condition here, you have to wait long enough (a few seconds is
>usually all that is needed) for the out of scope objects to be garbage
>collected, otherwise the same object will be used.)
The technical problem could be solved if the feature is good and important
to have. But let's not debate this. It is not central to our main
discussion. If you disagree, then okay.
>XBL, however, lets you define new methods and properties on the
>Element itself, cross-language, without any persistency problems
This can be solved orthogonally (not within XBL and the rest of it's
dependencies) if it is useful to make persistent interfaces on DOM which
are not standards. If this is truely needed, then it would be best to not
require XBL (and the rest of it's dependencies) in order to add such
interfaces. ORTHOGONAL is such a key word. Sorry for repeating it, but it
is true.
>> I have said at least twice that I do not want XSLT to be
>> interactive.
>
>You may not need a dynamic transformation language, but there is
>demand for it.
>
>Take this real world example:
>
>A <select> element that has two <option> elements is bound to XBL to
>give it presentation and event handlers that do selection, etc.
>
>Using the DOM, some script inserts new <option> elements into the
><select> element.
>
>Those <option> elements have to be rendered as part of the page
>immediately, with all the style and behaviour that the binding confers
>on those elements.
>
>XBL can do this.
This is a reasonable point. I did consider this in very beginning and my
observation is that the adding of content post markup (generated content)
is implementation dependent, so the transformations are best kept in the
implementation layer. In other words, you can write an XSLT transformation
that has behavior to add content within the implementation methaphor.
XBL merges the DOM implementation specifics such as DOM HTML and the
semantic binding. I have already explained in part 1 of this response why
it is best to put the implementation dependencies in that layer and keep
the semantic binding pure and orthogonal.
>> CSS was not designed to be required layer of DOM or markup.
>
>Neither is XBL. There is nothing about CSS or XBL that make them
>_required_. They are at the presentation layer.
Semantic binding basterdization. Refer to previous explanations in this post.
>The original document has all the semantics, and could be rendered in
>a language-specific UA, e.g. an XHTML+XForms document could be
>rendered without XBL in an XHTML+XForms UA. But with XBL and CSS
>enabled, then you could have the same document, in the same UA, withe
>the XForms controls looking different, e.g. replacing a <select> of
>country names with an interactive map of the world.
You can do semantic transformation to swappable implementation with XSLT.
>None of the semantics change: it's still "pick a country from this
>list". Only the presentation changes (from "combo box" to "map",
>although of course the difference is more complex at the code level).
Just one example of semantic basterdization should be sufficient:
When you change a single <A> tag from link/anchor to mean date, and not all
the <A> tags of the document, how is a search engine supposed to have any
idea what was meant??
>> You've been doing "commercial" development with XBL for apparently
>> some months now.
>
>I have never done any commercial work with XBL.
:-)
>> The examples I am being asked to rewrite in XSLT have some years of
>> development behind them.
>
>I came up with the "simple" demo in 30 minutes. The others did not
>take more than an hour or two each.
I meant the time you have spent learning and working with XBL and ditto for
the people who created the complex examples that Baron had asked me to
reproduce in XSLT.
>> I did not submit XBL to W3C.
>
>Neither did I, although I am indeed one of its more vocal proponents
>in the CSS working group.
And that is why it is important that I try my best to convince you about
the problem with merging the semantic binding layer and the implementation
layers.
Also eventually with examples to show you that the important use cases are
redundant with XSLT, which doesn't have the merging layers problem.
>> I am just provided a logical reasoning as to why it is W3C
>> redundant. It is up to the submitter to prove it is not, with
>> compelling use examples. It is up to you to work thru XSLT and prove
>> it can't be done.
>
>Actually it is common logical curtesey for the person making the
>positive assertion to back up that assertion:
You asserted that XSLT can not do a *specific* example of your choosing.
Thus it is your specific assertion. I only asserted that XBL is mostly
redundant and asked for *compelling* examples where it is not. I have not
denied that I will eventually need to share more complex examples of
compelling uses in order to make a convincing argument.
>| The burden of proof is always on the person asserting something.
>| Shifting the burden of proof, a special case of Argumentum ad
>| Ignorantiam, is the fallacy of putting the burden of proof on the
>| person who denies or questions the assertion. The source of the
>| fallacy is the assumption that something is true unless proven
>| otherwise.
> -- http://www.infidels.org/news/atheism/logic.html#shifting
Above.
>> I will share my work as I do it. But I will not be forced to play
>> useless mind games with no $ compensation.
>
>For the record, I am not paid for my W3C involvement. (Indeed I
>contribute at a quite significant financial cost to myself.)
Graciously noted.
[...]
>>> You are the first person I have seen claim that XSLT is able to
>>> solve this problem.
>>
>> The W3C Team said if before me. Apparently you did not read their
>> comments about the XBL submission:
>>
>> http://www.w3.org/Submission/2001/05/Comment
>>
>> "An alternative approach might be to use XSLT to transform a source
>> document to one that includes the fragments, although the disadvantage will
>> be that the DOM contains the expanded document and no longer only the
>> original. Also, this approach does not really reduce the number of
>> different technologies involved."
>
>The two disadvantages listed are pretty serious disadvantages, and the
>first is great enough to make this alternate approach unsuitable in
>the real world.
I disagree with your interpretation. They are advantages. I think the W3C
Team was commenting factually on cursory analysis, without interpreting
whether those "disadvantages" had any positive effects. They specifically
mention (encourage) further debate/input on this list. That is why I came
here to explain that separating the semantic binding ("DOM contains the
expanded document") is crucial. And also to explain that although "does
not really reduce the number of different technologies involved", that at
least the technologies are not merged. That orthogonal use is encouraged
and facilitated. I would have to repeat my numerous previous such as how
XSLT doesn't have to change to use XEvents or html events or any orthogonal
technology, and that XSLT runs every where now... etc..
>>>> I assume the timeline for XBL standards consideration can tolerate a
>>>> few months for competing examples.
>>>
>>> I am not aware of any W3C-led project to standardise XBL.
>>
>> Okay. I thought it had been submitted to W3C.
>
>Submission of a NOTE does not imply anything about contributions of
>W3C resources.
Okay, but since active development is happening with XBL, I think it is
also a service to developers to make these points now.
Since it is a W3C Note, then it is relevant to provide advance logic on
possibilities, so that developers can make inform decisions now about where
to invest their resources.
>>>>> 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
>>>
>>> Ironically, that error message is unrelated to XBL -- it is a bug
>>> in IE's XML DOM. That is to say, a bug with its W3C standards
>>> support.
>>
>> How about not using propoganda.
>
>This isn't propaganda. You said it did not work in IE, I explained
>why. It _is_ a bug, and not a lack of support, for what it's worth.
Netscape and Mozilla doesn't fully support XSLT. Should I call that a
"bug" or a lack of full support.
To me a bug is something that does not work as it was intended to by the
programmer. I am confident that MS intended for there to not be complete
conforming XML in that version of the browser.
>Anyway, that's not really relevant.
Agreed. Just the religious stuff I get annoyed sometimes, because it is
hippocritical. Both Mozilla and IE are imperfect. One is not evil and the
other a saint. My fault though for not ignoring it. I can ignore it for a
while, then I get saturated.
>> Or use XSLT, then it will run every where. I have made this point
>> about 4 times already in this thread.
>
>Claiming a technology is technically superior merely because it is
>standardised and widely implemented is a form of argumentum ad
>numerum. The technology should be reviewed on its own merits.
It was only one point of many for consideration. It is relevant point.
Thin orthogonal layers are easier to implement and maintain.
[...]
>>>> XSLT outputs XML and CDATA. That is about as general as you need to
>>>> do any W3 content.
>>>
>>> Actually, it is not sufficient. Arbitrary XML and CDATA cannot bind
>>> individual elements to CSS,
>>
>> I do not want them to!
>
>Which I think was my point. XSLT cannot do it. There is a demand for a
>technology that can.
As previously explained in detail in part 1 of this response, it reduces
the utility of semantic markup. It creates brittle dependencies. And it
isn't necessary to accomplish compelling examples (something I promise to
provide more of when I create them).
> You might not want it.
>
>But many people do.
I have agreed with right of personal preference many times in this thread.
That doesn't mean every badly designed personal preference should become a
web standard.
The key is to *show* people a better way. I agree with Ray Whitmer that
examples will be most instructive...
>> This is the semantic binding layer, not the style layer.
>
>XBL is at the style layer.
>
>This is important.
Covered this point already in this response.
>>> Arbitrary XML and CDATA (which is just a particular part of XML, so
>>> I'm not sure why you bring it out separately)
>>
>> CDATA to emphasize scripting capabilities
>
>Eh? What has CDATA to do with scripting?
Maybe I am wrong on this irrelevant detail, but I think the output of the
XSLT can be any CDATA which is what you need to encapsulate scripting from
the XML parser. I may have been confused on that. Any way it is not
relevant to our discussion. We agreed CDATA was part of XML.
>>> nor can [XSLT] extend the interface of individual DOM nodes without
>>> polluting the window's namespace.
>>
>> I refuted that already. See replies to Baron.
>
>Actually, you didn't. You simply said that a little pollution was ok:
>
> http://lists.w3.org/Archives/Public/www-style/2002Dec/0230.html
>
>...(search for "collision").
That reduced to one name only for the entire document without using XEvents.
You apparently missed the part about XEvents completely removes the issue.
http://lists.w3.org/Archives/Public/www-style/2002Dec/0230.html
>>> In practice, it's not even clear what the processing model for XSLT
>>> is: does it replace the original DOM
>>
>> It has nothing to do with DOM.
>
>XSLT has _everything_ to do with the DOM.
Critical false assumption. Do not ignore this point.
http://www.w3.org/TR/xslt
"This specification defines the syntax and semantics of XSLT, which is a
language for transforming XML documents into other XML documents."
XSLT merely transforms one XML document into another XML document. It is
so incredibly orthogonal to everything else, that it's only dependency is
XML. That is all it knows and all it cares about.
Yet it is simultaneously powerful enough to do semantic binding. This is
the beauty of proper OO orthogonal design. XSLT doesn't care if it's
output is parsed into a DOM or used to remap databases. It is universally
reuseable with the only dependency being that it tranforms XML only.
This is the crux of the problem with XBL. It has TOO much knowlegde about
TOO many layers built into it. Any book on OO design will tell you to
design your classes such that they minimize dependencies (specific
knowledge about) other classes.
I could write a book on this...
>Given one DOM and an XSLT transformation, XSLT produces a new DOM.
XSLT is not transforming DOM. You are viewing the W3C standards in a
DOM-centric perspective. XSLT transforms XML. That is all. Free your
mind from forcing dependencies and assumptions, so that your layers of
design can interopt maximally, and not become brittle from assumptions that
later change.
[...]
>>>> You can have behavior without DOM or CSS.
>>>
>>> I have yet to see this.
>>
>> My simple example with XSLT <select> was an example.
>
><select> has no defined behaviour.
>
>It has defined semantics, but UAs are free to implement those
>semantics however they like (a combo box, a map).
My simple canonical example showed that behavior of <select> could be
mapped by XSLT into semantically consistent presentation using radiobutton
behavior. It is swappable.
>XBL is a way of adding (optional) stylistic hints that say how to
>render the element and how it should behave.
It is also semantic binding.
We are getting to "broken record" repetition stage of the debate. We
either see each other's points and summarize our differences, or just stop.
>> XUL is an example. XUL doesn't require DOM does it?
>
>XUL, like HTML, does not require DOM, CSS, nor XBL. You could write a
>XUL UA that did not use any of those technologies.
Thanks. Just like XSLT doesn't require XHTML and thus doesn't require DOM,
CSS, etc..
>
>Of course to make it _do_ anything, just as with HTML, then you'll
>need to script the document (using the DOM), or else it will just be a
>non-interactive static document (like most HTML documents).
False. <select> is interactive without any scripting. One can make
semantic standards. It is an orthogonal activity to making extensible
semantic bindings (swapping of implementation).
>If you also want to control the rendering at a stylistic level, then
>you would use CSS and XBL.
CSS yes, but XBL not necessary.
*THAT* is the point of this thread:
1. That XBL is mostly redundant for compelling use cases
2. That CSS should not be merged with semantic bindings so it can be
swapped for implementation separately from semantics and so that CSS logic
doesn't basterdize utility of semantic layer and make brittle documents
which do not interopt.
> You don't want to use anything which changes
>the DOM, since that would break the aforementioned scripts. (You cannot
>transform the scripts; they might not even be in the same document.)
Refer back to the part of my response where I said:
-----
This is a reasonable point. I did consider this in very beginning and my
observation is that the adding of content post markup (generated content)
is implementation dependent, so the transformations are best kept in the
implementation layer. In other words, you can write an XSLT transformation
that has behavior to add content within the implementation methaphor.
XBL merges the DOM implementation specifics such as DOM HTML and the
semantic binding. I have already explained in part 1 of this response why
it is best to put the implementation dependencies in that layer and keep
the semantic binding pure and orthogonal.
-----
And:
-----
You are trying solve the problem of semantic standards by changing what
semantics is. Semantics is "consistent meaning" else it loses utility as a
layer.
Instead if you want certain custom tags to be a standard in DOM, then do
that. You will never provide infinite cases, but destroying consistent
semantic layer just so you can get custom tags in the DOM which mean
nothing to other layers (because they aren't standard custom tags), only
accomplishes reducing the utility of what semantic layer is for.
Not to mention how brittle every thing will get.
-----
And:
------
I only see that semantic layer is best left orthogonal. If DOM extensions
are needed they can be done with tranditional standards efforts such as DOM
HTML, DOM XHTML, DOM CSS. Will there be a DOM XSL-FO?? Etc..
------
-Shelby Moore
Received on Tuesday, 31 December 2002 22:21:57 UTC