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

Ian,

You are incredibly wrong in this one...


At 02:23 PM 1/2/2003 +0000, Ian Hickson wrote:
>
>On Wed, 1 Jan 2003, Shelby Moore wrote:
>>
>> At 03:13 AM 1/2/2003 +0000, Ian Hickson wrote:
>>> So would you agree with the following definitions?
>>>
>>>   Semantics
>>>      The intrinsic meaning of an element, [...].
>>>
>>>   Intrinsic
>>>      Of or relating to the essential nature of a thing.
>>>
>>>   Essential nature of an element
>>>      Its tag name.
>> 
>> Actually I can not agree that the essential nature of element _is_ its tag
>> name, because that is static.
>
>And that is the fundamental thing we disagree with.
>
>
>> The essential nature is the _interpretation_ of the tag name.
>
>That cannot be the case, because it implies that an element's
>essential meaning can change based on who is reading the markup, while
>the _entire point_ of semantic markup is that the meaning is well
>defined independent of the reader.


It is well defined by it's name, but as in all things in life,
interpretations vary.  One UA may decide to render the <select> with
nothing selected initially (zero or more) or another UA may initially
select the first item if none are marked as selected (one of more).  If the
<select> is fully qualified in HTML4, and the UA is supporting DOM HTML
(which is not the same animal as DOM Core), then this particular example my
not be open to interpretation in that specific case.

But generally the ability to apply multiple interpretations of tag names is
the incredible power of the semantic web.  The "meaning" is well defined.
The interpretation is a one-to-many phenomenon.  It is precisely what makes
the web more powerful than say PDF.



>(Not to mention that your statement is an oxymoron -- something's
>essential nature is orthogonal to its various interpretations.)


It is just because our definition is wrong.  And you helped me write the
statements.   We would be more accurate to say that semantics is the
"meaning" and the binding is the point of "associating interpretation" with
"meaning".

Ian if you are just trying to obfuscate by helping me into a english
mistake, then ambush me, then that is not in the spirit of production.  You
say about "your" statement.  It is "our" statement.  We were composing the
definitions with each other's assistance.  We are supposed to _help_ each
other find the correct definitions.  _help_ not _fight_

The bottom line of what I am saying in this thread regarding CSS is that
CSS associates interpretations of presentation with markup.  It has nothing
to do with associating interpretations of markup semantics.  Whereas,
defining new markup tags (as XBL does) is associating interpretations of
markup semantics.  The mechanism of association in XBL is combined with
features at the DOM and CSS layer.  Whereas the mechanism of association in
XSLT is orthogonal to the XHTML, DOM, CSS, everything except XML.

I want to keep mechanisms of semantic association above the parser and
above the DOM and CSS.  I think the benefits of that orthogonality outweigh
the convenience of merging the layers.  It is same as analogy of analyzing
why we sew our pant pockets but not our underwear (or our deodorant) to our
pants.  Sometimes we want to wear pants without underwear or deodorant.  It
is nice to not have them tied together.

All the DOM and CSS extensions in XBL could be in separate orthogonal
standards so we can use them from XSLT when we want to be reliant on DOM
and CSS in that sort of inseparable way.  But with XSLT approach we can
easily swap the transformations to avoid such dependencies because the
mechanism of association is at it's own orthogonal layer above the parser,
DOM, and CSS.

Again you never answered my assertion that the bi-directional arrow much be
placed between XBL and XHTML ("Semantics") in your ascii art diagram of layers.

Unless you can make a point which is conceptually direct to my point, I am
not going to respond to any more emails which are just obfuscation by
playing with fuzziness of english language.

I can agree with personal preference to merge the layers for convenience.
There is precedent of convenience methods in standards.  However, I will
not agree to attempts to befuddle my fundamental points with nonsense
filibusters.



>If a document contains an element, then that is the header 
>in that document, whatever twisted things may be done to it. 


Agreed and I not arguing inconsistently with that.  If you want to twist my
conceptual points, that is your political perogative.  It is not productive
for me.


 
>That is how we can have specifications like HTML or MathML, that 
>assign meaning to tag sets. 
> 
>>From the HTML4.01 spec: 
> 
># Each markup language defined in SGML is called an SGML application. 
># An SGML application is generally characterized by: [...] 
># 3. A specification that describes the semantics to be ascribed to 


Agreed "semantics" is "meaning".

"meaning" is open to interpretation which is a major point of the
flexibility of markup compared to things like PDF



># the markup. 
> -- http://www.w3.org/TR/html401/intro/sgmltut.html#h-3.1 
> 
>A specificiation that describes the semantics to be ascribed to the 
>markup. Not the default semantics, not the interpreted semantics, not 
>the semantics to assume if you don't feel like interpreting it in some 
>other way. 
> 
> 


Agreed, and is not inconsistent with my conceptual point.  If you want
to_help_ me get good definitions for my conceptual point, then please do.
If you are just trying to lay traps, then I have no interest.  My
conceptual points stand on their own merits.  The engish language is fuzzy
and it takes some community effort to get good definitions of conceptual
points.  You should understand my conceptual point by now???



>> This is what allows new interpretations when defining semantics thru 
>> binding. 
> 
>And conversely, the fact that the tag name is what defines an 
>element's semantics is


Agreed.  Semantics == "meaning".  It does not define _interpretation_.


> what ensures that CSS and XBL cannot do 
>semantic bindings, but XSLT can. CSS and XBL cannot change an 
>element's tag name at all, but XSLT can do so trivially. 


Baloney.

First, XBL has facility for defining and implementing entirely new tags and
it's bind thru CSS with -moz-dev.

Second, XBL is binding new interpretations of semantics.  The mechanism for
that in XBL is semantic binding.

If you do not understand that point by now, then I do not know how to help
you understand.  I can teach my 6 year old son that faster.

-Shelby Moore

Received on Thursday, 2 January 2003 16:35:55 UTC