5 ms·

Are we _really_ going to reinvent all the spectacularly bad ideas of XML, except this time in JSON?

DonHopkins 10y ago
I think you have make a distinction between "bad ideas of XML" and "essential ideas of CS that were implemented in XML because it was the fad at the time, and SGML before that, and are now being reimplemented in JSON, and will be reimplementing in the next big thing". It's like complaining about regular expressions "Are we _really_ going to reinvent all the spectacularly bad ideas of Perl, except this time in Python?
tonyedgecombe 10y ago
Seems so, just like how we are turning JavaScript into Java.
- martin-adams 10y ago
  But without a standard library
arethuza 10y ago
XSLT did have some nice bits - I still like XPath. Edit: Just to be clear some of the most terrifying code I've ever seen (and possibly wrote) was in XSLT.
- cowardlydragon 10y ago
  But but but it's FUNCTIONAL, and turing-complete!!! // yes I understand the use cases of functional code
  - DonHopkins 10y ago
    DSSSL [1], the SGML predecessor of XSLT and CSS, included a full blown built in Scheme interpreter, by the standard. That turned out to be a bit too much raw power and complexity for most people, so it never really caught on outside of the Boeing Airplane Maintenance Manual Publication Department and other big enterprisy SGML-loving organizations like that. Microsoft's non-standard implementation of XSLT [2] is "out of the tarpit" Turing complete [3] because it lets you write handlers in JavaScript and other languages, to actually get some useful work done and call external librarys, without bending over backwards. Of course Microsoft's non-standard extensions to XSLT aren't supported outside of Windows. But after using it, going back to plain XSLT was pretty frustrating to me, and in many cases it was easier just to forget about XSLT and write straight-up JavaScript code with XML parsing and XPath expressions. There's nothing that XSLT can do that you can't easily implement in a JavaScript library. At this point it's better to start with JavaScript and forget about XSLT, instead trying to use XSLT, hitting a wall, realizing you want to ship on some platform other than Windows, then rewriting it all in Java, then realizing you want it to run in the browser, then rewriting it all in JavaScript, which you should have started with in the first place. Another point for JavaScript: In the past decade, a whole hell of a lot more effort has been put into making JavaScript run fast, than making XSLT run fast. [1] https://en.wikipedia.org/wiki/Document_Style_Semantics_and_Specification_Language https://en.wikipedia.org/wiki/Document_Style_Semantics_and_S... [2] https://msdn.microsoft.com/en-us/library/bb986124.aspx https://msdn.microsoft.com/en-us/library/bb986124.aspx [3] https://en.wikipedia.org/wiki/Turing_tarpit https://en.wikipedia.org/wiki/Turing_tarpit
    - benibela 10y ago
      Isn't standard XSLT Turing complete anyways? Even XPath 3 is Turing complete
      - DonHopkins 10y ago
        The point is that XSLT is deeply stuck in the "Turing Tarpet": "Beware of the Turing tar-pit in which everything is possible but nothing of interest is easy." -Alan Perlis https://en.wikipedia.org/wiki/Turing_tarpit https://en.wikipedia.org/wiki/Turing_tarpit You would never want to write a JPEG decoder in XSLT, but the fact that it might be possible if you were willing to bend over backwards, write unmaintainable code that runs incredibly slowly and requires colossal amounts of memory, misses the point. For getting real work done in the real world, where big companies have mountains of data to process, and are required to pay real money for electrical power and computing equipment, Microsoft decided to add the ability to call JavaScript, Visual Basic, and other scripts from XSLT templates. Because it's just too hard to get anything of interest done in XSLT, and it's trivial and convenient in JavaScript, and there's probably already a library to do it.
        benibela 10y ago
        But it is not deeply in the tar-pit. Here is an raytracer written in XQuery: https://dev.w3.org/cvsweb/2011/QT3-test-suite/app/Demos/raytracer.xq?rev=1.2;content-type=text%2Fplain https://dev.w3.org/cvsweb/2011/QT3-test-suite/app/Demos/rayt... (imported modules are in the directory above) looks quite maintainable to me. XQuery is pretty much XPath-with-functions, and XPath 3 has anonymous functions, so you can directly translate it to XPath 3 by replacing `declare function foo(..` with `let $foo := function(...` Once it is XPath, you can put everything in a xsl:value-of tag.
        DonHopkins 10y ago
        I'd prefer to be on a mountain top far away from any tarpit, than only partially submerged in a tarpit. The mountain tops are modern JavaScript engines. How much work have Mozilla, Google, Apple, IBM and many other big organizations and excellent engineers poured into making XSLT run fast and efficiently in the last decade, compared to how much has been applied to JavaScript? Can you cite any interesting SIGPLAN articles about XSLT optimization? Have any commercial games shipped using a ray tracer implemented in XSLT?
- manarth 10y ago
  Increase the terror further by adding Jsonx to the mix: http://www.ibm.com/support/knowledgecenter/SS9H2Y_7.5.0/com.ibm.dp.doc/json_jsonx.html http://www.ibm.com/support/knowledgecenter/SS9H2Y_7.5.0/com....
  - arethuza 10y ago
    Isn't one of their examples invalid XML? http://www.ibm.com/support/knowledgecenter/SS9H2Y_7.5.0/com.ibm.dp.doc/json_jsonxconversionexample.html http://www.ibm.com/support/knowledgecenter/SS9H2Y_7.5.0/com.... Shouldn't <json:string name="ficoScore"> > 640</json:string> be <json:string name="ficoScore"> > 640</json:string>
    - manarth 10y ago
      It's one of the many peculiarities of XML: the "less-than" bracket is not allowed in text (because it could indicate the opening of a new XML tag), but the "greater-than" bracket does not need encoding when it's in text, because it's not ambiguous.
      - arethuza 10y ago
        I'm pretty sure most XML handling libraries would use > - never seen a raw > used in XML (though possible I might not have noticed). Edit: Forgot to say thanks for pointing that out!
        benibela 10y ago
        Just check what the W3C says about writing a raw >: > For characters such as > where XML defines a built-in entity but does not require its use in all circumstances, it is implementation-dependent whether the character is escaped. (https://www.w3.org/TR/xslt-xquery-serialization-31/#serphases https://www.w3.org/TR/xslt-xquery-serialization-31/#serphase...)
- benibela 10y ago
  If you like XPath and JSON, too, you can use my just updated Xidel (http://www.videlibri.de/xidel.html http://www.videlibri.de/xidel.html) to run XPath queries on JSON. It can do transformations, where you write the output structure, and then pick the values from the input JSON. E.g. to transform from {"a": [{"b": 123}, {"b": 456}]} to {"c": [123,456]}, you could write an XPath expression {"c": a/b }
cowardlydragon 10y ago
XPath is fantastic, although not everything is relevant to non-XML docs. But in general, JSON, XML, S-expressions, yaml, HTML, and many data interchange programs are all 95% the same hierarchical data structure. I wanted to make a cross-dataformat XPath subset that would work on all of them, and even allow a format that mixed the formats as needed in a MIME-esque document format, but the parser... oh god the parser. This guy's project was like the initial steps of mine: use whatever XML tools exist, but that kills streaming processing and doesn't pass cursory smell tests... I like this though, it is food for thought.
- zeveb 10y ago
  > But in general, JSON, XML, S-expressions, yaml, HTML, and many data interchange programs are all 95% the same hierarchical data structure. S-expressions can also represent graphs. I have a vague recollection that YAML can as well. An S-expression example: (nodes #1=(a #2=(b #1# #3=(c #2# #3#)) #3#) #2# #3#)
  - junke 10y ago
    Worth noting that you can both read and print such forms.
    - zeveb 10y ago
      > Worth noting that you can both read and print such forms. That's actually how I checked that I had the syntax right: I wrote: (let ((*print-circle* t) (*print-case* :downcase) (print '(nodes #1=(a #2=(b #1# #3=(c #2# #3#)) #3#) #2# #3#)) nil) Thus proving that reading & printing work well. Seriously, Lisp is an awesome language.
  - mmastrac 10y ago
    Firefox's Spidermonkey used to support a similar notation for JS objects. I can't remember when it was removed, but it was pretty obscure: http://blog.notdot.net/2006/9/Serializing-JavaScript-objects-with-circular-references http://blog.notdot.net/2006/9/Serializing-JavaScript-objects... http://philogb.github.io/blog/2009/03/24/sharp-variables/ http://philogb.github.io/blog/2009/03/24/sharp-variables/ https://developer.mozilla.org/en-US/docs/Archive/Web/Sharp_variables_in_JavaScript https://developer.mozilla.org/en-US/docs/Archive/Web/Sharp_v...
falcolas 10y ago
The fact that we keep re-implementing ideas like this means that there are a lot of valid use-cases for this kind of tool. The same applies to (JSON|XML)RPC, xpath|jq, and schemas. There are even folks currently developing namespaces for JSON! I think it's human nature, as often as I see it repeating throughout history (and not just in the tech industry). Just wait, there will be a new JSON just over the horizon which will close the circle and bring back a very simplistic serialization format with a minimal number of built-in structures. Perhaps it would be better to create a C++ of serialization formats, all the features out of the gate, so you can pick and choose from the beginning. Again, I think human nature means we can't go back to XML (too much horror associated with SOAP and WSDL), or even continue with JSON (custom and subtly incompatible parsers being built around the core to handle missing features).
- niftich 10y ago
  This cycle keeps re-occurring in multiple places every few years because the ideas are in fact useful, but the surrounding ecosystem falls out of favor. Old solutions accumulate cruft and start to need more expertise (and sometimes, straight wisdom) to operate well. People complain, blog posts are written, inertia and inaction are challenged; babies are thrown out of the bathwater as clean-room rewrites commence with different stacks, different tradeoffs, and often, different bikeshedding. The new, shiny tool is promoted on its merits; some of that excitement inspires hype, which takes on a life of its own. Through a combination of informed usage and less-informed codemashing, the tool accumulates users from all walks of life, who turn into willing or unwilling stakeholders in its future. Development pressures pull the product in different ways, some people leave, eventually only the really passionate or really locked-in remain. These people acquire domain knowledge, "sometimes straight wisdom", making the solution -- its merits, design rationale, tradeoffs, and lessons learned -- more opaque to newcomers. Those newcomers find that existing solutions don't appear to do what they need at the level of complexity that they can grok. The cycle repeats.
- jpatokal 10y ago
  > a very simplistic serialization format with a minimal number of built-in structures. It's already here: protobufs. https://en.wikipedia.org/wiki/Protocol_Buffers https://en.wikipedia.org/wiki/Protocol_Buffers
mhd 10y ago
As if we're not already doing that. JSON configs are quite popular (e.g. package.json), and it's not really a format made for human consumption. We all cried about the abuse of XML and its inherent foibles, but I seriously doubt that replacing that with JSON and Markdown was the best choice.

I think you have make a distinction between "bad ideas of XML" and "essential ideas of CS that were implemented in XML because it was the fad at the time, and SGML before that, and are now being reimplemented in JSON, and will be reimplementing in the next big thing". It's like complaining about regular expressions "Are we _really_ going to reinvent all the spectacularly bad ideas of Perl, except this time in Python?

tonyedgecombe 10y ago

Seems so, just like how we are turning JavaScript into Java.

martin-adams 10y ago
But without a standard library

arethuza 10y ago

XSLT did have some nice bits - I still like XPath. Edit: Just to be clear some of the most terrifying code I've ever seen (and possibly wrote) was in XSLT.

cowardlydragon 10y ago
But but but it's FUNCTIONAL, and turing-complete!!! // yes I understand the use cases of functional code
- DonHopkins 10y ago
  DSSSL [1], the SGML predecessor of XSLT and CSS, included a full blown built in Scheme interpreter, by the standard. That turned out to be a bit too much raw power and complexity for most people, so it never really caught on outside of the Boeing Airplane Maintenance Manual Publication Department and other big enterprisy SGML-loving organizations like that. Microsoft's non-standard implementation of XSLT [2] is "out of the tarpit" Turing complete [3] because it lets you write handlers in JavaScript and other languages, to actually get some useful work done and call external librarys, without bending over backwards. Of course Microsoft's non-standard extensions to XSLT aren't supported outside of Windows. But after using it, going back to plain XSLT was pretty frustrating to me, and in many cases it was easier just to forget about XSLT and write straight-up JavaScript code with XML parsing and XPath expressions. There's nothing that XSLT can do that you can't easily implement in a JavaScript library. At this point it's better to start with JavaScript and forget about XSLT, instead trying to use XSLT, hitting a wall, realizing you want to ship on some platform other than Windows, then rewriting it all in Java, then realizing you want it to run in the browser, then rewriting it all in JavaScript, which you should have started with in the first place. Another point for JavaScript: In the past decade, a whole hell of a lot more effort has been put into making JavaScript run fast, than making XSLT run fast. [1] https://en.wikipedia.org/wiki/Document_Style_Semantics_and_Specification_Language https://en.wikipedia.org/wiki/Document_Style_Semantics_and_S... [2] https://msdn.microsoft.com/en-us/library/bb986124.aspx https://msdn.microsoft.com/en-us/library/bb986124.aspx [3] https://en.wikipedia.org/wiki/Turing_tarpit https://en.wikipedia.org/wiki/Turing_tarpit
  - benibela 10y ago
    Isn't standard XSLT Turing complete anyways? Even XPath 3 is Turing complete
    - DonHopkins 10y ago
      The point is that XSLT is deeply stuck in the "Turing Tarpet": "Beware of the Turing tar-pit in which everything is possible but nothing of interest is easy." -Alan Perlis https://en.wikipedia.org/wiki/Turing_tarpit https://en.wikipedia.org/wiki/Turing_tarpit You would never want to write a JPEG decoder in XSLT, but the fact that it might be possible if you were willing to bend over backwards, write unmaintainable code that runs incredibly slowly and requires colossal amounts of memory, misses the point. For getting real work done in the real world, where big companies have mountains of data to process, and are required to pay real money for electrical power and computing equipment, Microsoft decided to add the ability to call JavaScript, Visual Basic, and other scripts from XSLT templates. Because it's just too hard to get anything of interest done in XSLT, and it's trivial and convenient in JavaScript, and there's probably already a library to do it.
      - benibela 10y ago
        But it is not deeply in the tar-pit. Here is an raytracer written in XQuery: https://dev.w3.org/cvsweb/2011/QT3-test-suite/app/Demos/raytracer.xq?rev=1.2;content-type=text%2Fplain https://dev.w3.org/cvsweb/2011/QT3-test-suite/app/Demos/rayt... (imported modules are in the directory above) looks quite maintainable to me. XQuery is pretty much XPath-with-functions, and XPath 3 has anonymous functions, so you can directly translate it to XPath 3 by replacing `declare function foo(..` with `let $foo := function(...` Once it is XPath, you can put everything in a xsl:value-of tag.
        DonHopkins 10y ago
        I'd prefer to be on a mountain top far away from any tarpit, than only partially submerged in a tarpit. The mountain tops are modern JavaScript engines. How much work have Mozilla, Google, Apple, IBM and many other big organizations and excellent engineers poured into making XSLT run fast and efficiently in the last decade, compared to how much has been applied to JavaScript? Can you cite any interesting SIGPLAN articles about XSLT optimization? Have any commercial games shipped using a ray tracer implemented in XSLT?
manarth 10y ago
Increase the terror further by adding Jsonx to the mix: http://www.ibm.com/support/knowledgecenter/SS9H2Y_7.5.0/com.ibm.dp.doc/json_jsonx.html http://www.ibm.com/support/knowledgecenter/SS9H2Y_7.5.0/com....
- arethuza 10y ago
  Isn't one of their examples invalid XML? http://www.ibm.com/support/knowledgecenter/SS9H2Y_7.5.0/com.ibm.dp.doc/json_jsonxconversionexample.html http://www.ibm.com/support/knowledgecenter/SS9H2Y_7.5.0/com.... Shouldn't <json:string name="ficoScore"> > 640</json:string> be <json:string name="ficoScore"> > 640</json:string>
  - manarth 10y ago
    It's one of the many peculiarities of XML: the "less-than" bracket is not allowed in text (because it could indicate the opening of a new XML tag), but the "greater-than" bracket does not need encoding when it's in text, because it's not ambiguous.
    - arethuza 10y ago
      I'm pretty sure most XML handling libraries would use > - never seen a raw > used in XML (though possible I might not have noticed). Edit: Forgot to say thanks for pointing that out!
      - benibela 10y ago
        Just check what the W3C says about writing a raw >: > For characters such as > where XML defines a built-in entity but does not require its use in all circumstances, it is implementation-dependent whether the character is escaped. (https://www.w3.org/TR/xslt-xquery-serialization-31/#serphases https://www.w3.org/TR/xslt-xquery-serialization-31/#serphase...)
benibela 10y ago
If you like XPath and JSON, too, you can use my just updated Xidel (http://www.videlibri.de/xidel.html http://www.videlibri.de/xidel.html) to run XPath queries on JSON. It can do transformations, where you write the output structure, and then pick the values from the input JSON. E.g. to transform from {"a": [{"b": 123}, {"b": 456}]} to {"c": [123,456]}, you could write an XPath expression {"c": a/b }

cowardlydragon 10y ago

XPath is fantastic, although not everything is relevant to non-XML docs. But in general, JSON, XML, S-expressions, yaml, HTML, and many data interchange programs are all 95% the same hierarchical data structure. I wanted to make a cross-dataformat XPath subset that would work on all of them, and even allow a format that mixed the formats as needed in a MIME-esque document format, but the parser... oh god the parser. This guy's project was like the initial steps of mine: use whatever XML tools exist, but that kills streaming processing and doesn't pass cursory smell tests... I like this though, it is food for thought.

zeveb 10y ago
> But in general, JSON, XML, S-expressions, yaml, HTML, and many data interchange programs are all 95% the same hierarchical data structure. S-expressions can also represent graphs. I have a vague recollection that YAML can as well. An S-expression example: (nodes #1=(a #2=(b #1# #3=(c #2# #3#)) #3#) #2# #3#)
- junke 10y ago
  Worth noting that you can both read and print such forms.
  - zeveb 10y ago
    > Worth noting that you can both read and print such forms. That's actually how I checked that I had the syntax right: I wrote: (let ((*print-circle* t) (*print-case* :downcase) (print '(nodes #1=(a #2=(b #1# #3=(c #2# #3#)) #3#) #2# #3#)) nil) Thus proving that reading & printing work well. Seriously, Lisp is an awesome language.
- mmastrac 10y ago
  Firefox's Spidermonkey used to support a similar notation for JS objects. I can't remember when it was removed, but it was pretty obscure: http://blog.notdot.net/2006/9/Serializing-JavaScript-objects-with-circular-references http://blog.notdot.net/2006/9/Serializing-JavaScript-objects... http://philogb.github.io/blog/2009/03/24/sharp-variables/ http://philogb.github.io/blog/2009/03/24/sharp-variables/ https://developer.mozilla.org/en-US/docs/Archive/Web/Sharp_variables_in_JavaScript https://developer.mozilla.org/en-US/docs/Archive/Web/Sharp_v...

falcolas 10y ago

The fact that we keep re-implementing ideas like this means that there are a lot of valid use-cases for this kind of tool. The same applies to (JSON|XML)RPC, xpath|jq, and schemas. There are even folks currently developing namespaces for JSON! I think it's human nature, as often as I see it repeating throughout history (and not just in the tech industry). Just wait, there will be a new JSON just over the horizon which will close the circle and bring back a very simplistic serialization format with a minimal number of built-in structures. Perhaps it would be better to create a C++ of serialization formats, all the features out of the gate, so you can pick and choose from the beginning. Again, I think human nature means we can't go back to XML (too much horror associated with SOAP and WSDL), or even continue with JSON (custom and subtly incompatible parsers being built around the core to handle missing features).

niftich 10y ago
This cycle keeps re-occurring in multiple places every few years because the ideas are in fact useful, but the surrounding ecosystem falls out of favor. Old solutions accumulate cruft and start to need more expertise (and sometimes, straight wisdom) to operate well. People complain, blog posts are written, inertia and inaction are challenged; babies are thrown out of the bathwater as clean-room rewrites commence with different stacks, different tradeoffs, and often, different bikeshedding. The new, shiny tool is promoted on its merits; some of that excitement inspires hype, which takes on a life of its own. Through a combination of informed usage and less-informed codemashing, the tool accumulates users from all walks of life, who turn into willing or unwilling stakeholders in its future. Development pressures pull the product in different ways, some people leave, eventually only the really passionate or really locked-in remain. These people acquire domain knowledge, "sometimes straight wisdom", making the solution -- its merits, design rationale, tradeoffs, and lessons learned -- more opaque to newcomers. Those newcomers find that existing solutions don't appear to do what they need at the level of complexity that they can grok. The cycle repeats.
jpatokal 10y ago
> a very simplistic serialization format with a minimal number of built-in structures. It's already here: protobufs. https://en.wikipedia.org/wiki/Protocol_Buffers https://en.wikipedia.org/wiki/Protocol_Buffers

mhd 10y ago

As if we're not already doing that. JSON configs are quite popular (e.g. package.json), and it's not really a format made for human consumption. We all cried about the abuse of XML and its inherent foibles, but I seriously doubt that replacing that with JSON and Markdown was the best choice.