Comment by jeromeparadis | Hacker News Reader

Comment by jeromeparadis | Hacker News Reader

Parent Full thread

Totally agree.

In my opinion, the problem of separation of data and presentation won't be solved by markup or CSS.

If a Web page is to contain data and a service wants to act on this data, it has to scrape the Web page. Which is even harder with scripted pages. But scraping data isn't a solution. The semantic web may try to have web developers bring sense to data on a web page, but the problem remains. It's just a markup patch. It's doesn't define how to act on that data. Web Intents are just another patch to markup to bring verbs.

Direct access to the data sources with well define methods to act on that data and interact with it (instead of using form) is what works today through APIs. What doesn't work is that there aren't a lot of open standards APIs. Most well used APIs are proprietary and Facebook's a good example. I believe standard bodies should put their brains and efforts on defining API standards. Some standards APIs some clunky, are in use in B2B in the back ends but there's not much of it on the consumer facing Web. We must move forward to push separation of presentation, data and verbs for the whole Web, one small step at a time.

If most use cases on the Web used standard APIs, we would have true separation of content and presentation. We would even have the verbs to exchange/create understandable content. Then, you can use HTML/CSS to adapt a UI to any device with true separation.

That's the way we build apps and sites today and with standard, it would pave the way to a more exciting future.

So one day, if I want to have my own customized UI for that new holographic/gesture recognition device to shop with my preferred merchants, I just have to build an app and I'll be able to browse their merchandise, sort it like I want and finalize a transaction without even visiting their Web site.

>If a Web page is to contain data and a service wants to act on this data, it has to scrape the Web page.

This is completely the wrong approach and this isn't how people who know what they're doing work now.

A web page is just a presentation layer. If you have a service that wants data, it needs to work with a model or presenter/controller layer. On the web this can be a REST service, SOAP, something proprietary, etc. Ideally, the web site will be using this same source to get its data.

If the web application presents data via a web interface and doesn't offer a presentation/controller layer to allow you to access that same underlying API, then yes, you will have to scrape if you want that data for some reason. But I don't see this as wrong, you're doing something the owners of the data didn't intend for you to do. You'll have similar issues if you want to get data out of any application view (e.g. screen scraping a windows native app).

EDIT: Read the rest of your post and I see that you addressed much of this already. I still maintain that this is already how people are working who want others to use their data.

> I believe standard bodies should put their brains and efforts on defining API standards.

Have you seen SOAP?

He said put brains into it.

Not in a sense: "Throw your brains in for zombies to have a party". But in a sense that one should try and think and find protocols which are elegant in a sense that it makes reasoning about and using them easy and simple.

I agree that coming up with SOAP and XML-RPC took quite some brains and effort, too bad that some really good people had to be lobotomized for it.

Yes. I prefer something more lightweight. But SOAP is a protocol. What I propose are standards for common use cases that are not as general purpose.

Example, Facebook API allows querying, interacting with the social graph, profiles, photos, feeds, events, etc. These are use cases commonly used on photo apps, social networks, eventing, etc. But it's proprietary. Now imagine an open source standard similar to that but that can define such building blocks including other scenarios such as contacting a web site owner (about page, contact page), querying/posting articles to a web site, querying/doing transactions with products/services, etc. Once you go through all scenarios, then the problem that remains will be more about agents/authorities/reputation/security of allowing someone to interact with services. With better access for apps to interact directly with content by bypassing the current web presentation layer to avoid spam/fraud.

Reply on news.ycombinator.com