Comment by angrybards
21 hours ago
HTML markup designed for presentation doesn't always map well to the relationships JSON-LD is used to describe which I imagine is probably why Microdata didn't work out. I have an idea which might use it, but it is a simple use case that doesn't try do too much. Microdata requires the agent supports a more complex HTML parser, Finding a script tag in the document head is probably simpler.
I wouldn't dismiss REST because of RCP though. HTTP and HTML's success probably relate to how Roy Fielding's REST constraints kept the HTTP protocol lean and extendable. It is more like RCP is being used as a layer over top of REST because of HTTP's and HTML's success as being good technologies for web scale.
Personally I'm of the camp that HTNL schema data should only represent what's visually displayed, much like how accessibility is usually done. In that way I like Microdata because it reinforces that if there isn't a DOM node showing price, for example, I shouldn't be showing that data in a visually hidden way.
For REST, I think the only reason HTML has been useful this long is because of the REST ideas that Fielding gave a name to. Today people just don't use it much, too many sites lean on client side rendering and fetching data from JSON RPC calls that we call REST.
I prefer REST, hell I wish we had proper XSLT 3.0 support for client side rendering logic without JavaScript.
I don't fully understand XSLT, but I've been building something which I believe solves a similar problem (albeit JSON-LD and Javascript). The general XML ecosystem of solutions have always looked really complex to me. You need to understand a lot more types/elements than I think is reasonable for people to author with but they are from before my time. I took a look at XForms 2 and it had its own way of defining functions which on top of the other XML quirks has security concerns.
Oh I can't say I like XML and XSLT for the syntax or (lack of) terseness. I appreciate how it handles templating via selectors, logical operations, and runs as a first party templating engine in the DOM without depending on the JS runtime.
I once built a full RSS reader in XSLT. I had to proxy requests to avoid CORs, but it was all based on an XSLT template for OPMLs that would fetch each feed, parse them, chuck the description into HTML including CData parsing, and combine all feeds to sort by date.
It was far from a perfect setup, partly due to browsers having been decades out of date with XSLT, but it gully leveraged browser caching for feeds. Caching in RSS readers is usually really bad from ignoring caching all together and polling frequently to misusing cache mechanisms and causing weird behavior for feed hosts. Letting a browser handle it to spec was great.
1 reply →