On Sat, 2010-12-04 at 16:38 -0500, David Lee wrote:
> I'll stil bite and raise you a devils-avococate.
> Explain to me why its "better" that XML be translated in the browser
> to presentation then on the server.
> In either case someone has to author the translation buisiness logic
> (be it XSLT, CSS or whatever).
> So what is the advantage to having this done in the browser vs the
> server (or whatever "smart filesystem" or "database" is "serving" the
> XML content).
> Compare/contrast that to the cost of requiring ALL browsers in the
> entire world to adopt your technology vs only requiring the server
> hosting the particular content to adopt it.
All browsers already support XML to some degree. They also support all
of the behavior we'd be mandating. All they need to do is flag that the
behavior can be applied from CSS as well as native HTML. It isn't rocket
science, by any means.
And you prove my point about the technology. If I say to the average web
developer, "Take this markup content and apply translational business
logic to it via an external transformational language into an emphasized
indigo," they're going to look at me as if I were insane.
If I say the exact same thing phrased as, "Can you make the 'span' tags
with the class 'awesome' bold and purple?", they're going to nod and
have no issue with it.
This the explicit difference between the application developer mindset
that you and Bill Clare are promoting (which is, by the by, pretty much
the audience XML speaks to right now) and the web developer population
(an audience we've never managed to reach, that is far larger than the
former).
The advantage was stated explicitly in my previous email: there are
ubiquitous and well-understood technologies we can leverage. Doing so is
easy, when compared with other solutions. This is low-hanging fruit.
--->Ben