3 ms·

> but I fear we're starting to slip back a bit into a client-side dynamic web phase that isn't accessible, not semantic and overall app focused I agree with th

by modarts 13y ago

> but I fear we're starting to slip back a bit into a client-side dynamic web phase that isn't accessible, not semantic and overall app focused I agree with the overall sentiment that content should be accessible; but one thing you aren't taking into account with the above statement are the channels by which we access the content. Today REST APIs are that channel, and serve as the backends for the dynamic heavy client apps, as well as a medium for other services/applications/users to interact with and consume that content. I'd argue that it allows for an even more semantic manifestation of data and content, since we aren't limited to defining semantics with just a series of tags wrapping content; served to clients in large homogenous blobs of HTML in readonly fashion. Instead we expand our conceptual space to include HTTP verbs, headers, and URLs to provide an interactive interface to data that far eclipses what the "Semantic Web" movement was ever able to deliver.

eksith 13y ago
Fair enough. But then a REST API isn't a panacea since browsers(or content parsing apps) need go through a new iteration from rendering content "as-styled" to "as-meant" for a semantic web. We don't have that yet and it doesn't look like vendors are going down that path any time soon. Then there's the question of text-only browsers like Lynx. A semantic web as you describe isn't the current web at all, but a new completely new layer on top of it.
- dredmorbius 13y ago
  Readability, Instapaper, and Pocket all do a pretty good job of "as meant" for sites. The do this through a server-based solution, with some reliance on standards, but also, I'll suspect, a large number of site-specific parsing and formatting rules.
gambler 13y ago
even more semantic manifestation expand our conceptual space What exactly does all of that mean? REST is just a subprotocol of HTTP. It does add some guarantees about server behavior, but it does not make chunks of JSON any more semantic than if they were served over FTP. The simplest example of why HTML is semantic (and the underlying benefits) is the very textarea I'm writing this in. I can resize it to accommodate larger messages I'm typing. It does spell-checking. The functionality was developed once and now benefits thousands of people visiting thousands of websites. Moreover, I can rely on it and control it. All of this thanks to semantic difference between textarea and some random div. This wouldn't be possible with some random JSON format or custom JavaScript control.

by modarts 13y ago

eksith 13y ago

Fair enough. But then a REST API isn't a panacea since browsers(or content parsing apps) need go through a new iteration from rendering content "as-styled" to "as-meant" for a semantic web. We don't have that yet and it doesn't look like vendors are going down that path any time soon. Then there's the question of text-only browsers like Lynx. A semantic web as you describe isn't the current web at all, but a new completely new layer on top of it.

dredmorbius 13y ago
Readability, Instapaper, and Pocket all do a pretty good job of "as meant" for sites. The do this through a server-based solution, with some reliance on standards, but also, I'll suspect, a large number of site-specific parsing and formatting rules.

gambler 13y ago

even more semantic manifestation expand our conceptual space What exactly does all of that mean? REST is just a subprotocol of HTTP. It does add some guarantees about server behavior, but it does not make chunks of JSON any more semantic than if they were served over FTP. The simplest example of why HTML is semantic (and the underlying benefits) is the very textarea I'm writing this in. I can resize it to accommodate larger messages I'm typing. It does spell-checking. The functionality was developed once and now benefits thousands of people visiting thousands of websites. Moreover, I can rely on it and control it. All of this thanks to semantic difference between textarea and some random div. This wouldn't be possible with some random JSON format or custom JavaScript control.