Cart
[Home] [By Thread] [By Date] [Recent Entries]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
