RE: [xml-dev] XML-DEV list

["Len Bullard" <cbullard@hiwaay.net>]

From: andrew welch [mailto:andrew.j.welch@gmail.com] 

"All inbound-linking systems that scale out of some boundary share
that characteristic without filtering controls."

>I could quote some more but the entire paragraph makes for impossible
>reading.  The points you make could change my opinion, you could be
>saying absolute gold - I just can't distill it down into something
>comprehensible.

Spend some time in the library learning about second order systems.  In your
mode of learning, you can only understand what you already know.  Or you
might want to read some recent posts others are making about the silliness
of basing opinions on Google ranking.  Here's a recent one:

http://www.tbray.org/ongoing/When/200x/2006/09/24/Image-Search

If you can understand that, you may have a clue.

>I guess its time I went back to quietly ignoring your posts

Ok, just do it quietly.

>> 2.  Adding more semantics to CSS bloats the browser.
>> 3.  Bloating the browser may be a good tradeoff if authors are more
>>   productive or interoperability improves.  The first is likely but the
>>   second is not.

>Thats subjective isn't it?  

And attaching linking semantics in a CSS declaration is somehow more
objective?

Someone soon will suggest that keeping all of this independent of any
particular syntax will be better.  That will bring us back around to the
architectural forms era.  And so it goes.

Do you have any new ideas or is this simply and only the latest in a series
of attempts to move the semantic hooks into CSS?  Again, have at.  It isn't
wrong; it just isn't different, innovative or something likely to do more
that what we already have.  The enemy of good is more.  Now if you can make
the point that somehow this improves the web in ways that everyone can
benefit by, by all means, have at the standards too.  Otherwise, it's just
more.  I'm not attacking, fudding or filling your thread (which is now a
hijacked thread from the original) with noise; I'm asking why this solution
is better than the others.  Given what I read so far, it weakens the system
by confusing the layering and by ignoring that linking (the process) is
overloaded already.

http://www.sdtimes.com/fullcolumn/column-20060901-05.html

Not that XML is automatically the only and best solution either.  That is
why a review of the historical attempts to solve the problem is useful, but
also because it might be a good idea to better define what the problem is.
I'm waiting to read Ben's paper because so far, it hasn't been defined here
by the author although Peter and others have done a good job of that.

>If the rules weren't in CSS but in a separate XML file the browser would
>still need to parse that file.  If XML were used for that link file, then
>its likely this would be larger than the equivalent in CSS, causing even
>more "bloat

It only reduces existing bloat if by doing what you want something else is
taken away.

len