4 ms·

>It would be cumbersome and error-prone to try to download this HTML, parse it and try to extract information from it This is the crux of the problem. Also the

>It would be cumbersome and error-prone to try to download this HTML, parse it and try to extract information from it This is the crux of the problem. Also the reason XML fell out of favor and lead to a massive and still incomplete reinvention of the wheel in the form of JSON schema etc. Imagine a client side programming language for which a valid html snippet is simply the serialization of an object. And vice versa. No parsing required. The point is that much of the web has been shaped by the adoption of javascript as the exclusive browser side programming language.

evnix 3y ago
Yeah it's interesting how XML/XHTML was both data and presentation, we completely gave that up for a much inferior JSON format. Most of this was due to the overuse of XML, but it seems we are heading in that direction with either JSON or YAML everywhere these days. The usual complaint is XML is bloated, but it is really how you write it, { "Name":"John", "age":20} Vs <name="John" age="20" /> and XML gives you both types and presentation with DTD and XSLT
- ororoo 3y ago
  I often see variants like this in xml: <item> <Name>John</Name> <Age>20</Age> </item> or <item_John age="20"/> where john is parsed manually out of item object or full blown up insanity <person> <item> <key>name</key> <value>John</value> </item> <item> <key>age</key> <value>20</value </item> </person>
- nologic01 3y ago
  There are more peculiarities with XML, e.g., the ambiguity of attributes vs nested elements (you could also write <name="John"><age>20</age></name> to express the same thing) but these don't feel insurmountable. You could pin down a subset based on extra rules that would simplify working with XML/XHTML and obviate the need to invent a parallel universe in the form of JSON. You mention the data/presentation mix and that is not necessarily an advantage - separation of duties is usually a good idea, unless you can properly channel that "efficiency". But that too seems not insurmountable: the real, visual presentation on screen is anyway delegated to CSS. The (X)HTML structure is still in a sense supposed to capture the logical structure of the document/object that is being transmitted. What would be required is a way for the client-side language to distill the data-centric logic from the occasionally inflationary use of things like <div> elements (which seems another hack trying to fix poor design anyway). In any case, no point crying over spilled milk. The winner-takes-all nature of the web means it is doomed to be building on the hacks adopted by the dominant entities to solve their needs. A historical accident that keeps giving. Who knows, maybe as the browser is enabled with WASM and whatnot there will be a chance in the future to have a more rational approach to API's, REST, Hypermedia, Linked Data and that magical universe.
- wumms 3y ago
  > <name="John" age="20" /> As far as I know, that is not well-formed XML; the tag name is missing. You'd have to write it like this: <person name="John" age="20" />

evnix 3y ago

Yeah it's interesting how XML/XHTML was both data and presentation, we completely gave that up for a much inferior JSON format. Most of this was due to the overuse of XML, but it seems we are heading in that direction with either JSON or YAML everywhere these days. The usual complaint is XML is bloated, but it is really how you write it, { "Name":"John", "age":20} Vs <name="John" age="20" /> and XML gives you both types and presentation with DTD and XSLT

ororoo 3y ago
I often see variants like this in xml: <item> <Name>John</Name> <Age>20</Age> </item> or <item_John age="20"/> where john is parsed manually out of item object or full blown up insanity <person> <item> <key>name</key> <value>John</value> </item> <item> <key>age</key> <value>20</value </item> </person>
nologic01 3y ago
There are more peculiarities with XML, e.g., the ambiguity of attributes vs nested elements (you could also write <name="John"><age>20</age></name> to express the same thing) but these don't feel insurmountable. You could pin down a subset based on extra rules that would simplify working with XML/XHTML and obviate the need to invent a parallel universe in the form of JSON. You mention the data/presentation mix and that is not necessarily an advantage - separation of duties is usually a good idea, unless you can properly channel that "efficiency". But that too seems not insurmountable: the real, visual presentation on screen is anyway delegated to CSS. The (X)HTML structure is still in a sense supposed to capture the logical structure of the document/object that is being transmitted. What would be required is a way for the client-side language to distill the data-centric logic from the occasionally inflationary use of things like <div> elements (which seems another hack trying to fix poor design anyway). In any case, no point crying over spilled milk. The winner-takes-all nature of the web means it is doomed to be building on the hacks adopted by the dominant entities to solve their needs. A historical accident that keeps giving. Who knows, maybe as the browser is enabled with WASM and whatnot there will be a chance in the future to have a more rational approach to API's, REST, Hypermedia, Linked Data and that magical universe.
wumms 3y ago
> <name="John" age="20" /> As far as I know, that is not well-formed XML; the tag name is missing. You'd have to write it like this: <person name="John" age="20" />