5 ms·

Why do I see things like this and still think that XML and XSLT made a lot of this stuff very simple and portable and that we lost a good bit of progress by cho

by buro9 6y ago

Why do I see things like this and still think that XML and XSLT made a lot of this stuff very simple and portable and that we lost a good bit of progress by choosing JSON, YAML, etc after we already had great validation of schemas, translation, streaming and DOM parsing, etc.

lmm 6y ago
I'm guessing it's because you haven't tried to write an XSLT recently. Yes, it's a way to declarative express transformations which has a lot of elegant theoretical properties. But that doesn't matter when it's so, so painfully tedious to actually write.
- saurik 6y ago
  XSL/T just kept getting better; like, I agree with exactly what you said for 1.0--which sadly is all libxslt (and thereby browsers that relied on it) ever supported--but XSL/T 2.0 was pretty epic, and there is now even a 3.0 as of a few years ago.
  - emmanueloga_ 6y ago
    Agreed, XSLT 3.0 is amazing... and XQuery provides a more palatable syntax, with similar semantics. Kinda ironic that given the problem definition no solution has been provided on XQuery or XSLT yet, the widely used domain specific languages that better suit the problem :-). I believe there's a lot of inspiration to be had from the X-family of languages. The "secret sauce" is XPath. We need a new language drawing inspiration from the tree processing of X* languages but with more modern syntax and less with a less byzantine type system (read: anything but XML Schema :-). Less angle brackets would help too! --- Bonus points: add tuples and prolog like queries to such language (thinking of SPARQL) ... now that would be something really powerful.
    - bmn__ 6y ago
      > We need a new language drawing inspiration This exists (optics/lenses), but most programmers don't know about it. I expect this to hit mainstream programming languages a few years later. I don't know of a simple, jargon-free explanation of the concepts. WP is useless, sadly. http://enwp.org/Bidirectional_transformation http://enwp.org/Bidirectional_transformation Also see: https://news.ycombinator.com/item?id=24710565 https://news.ycombinator.com/item?id=24710565
      - josevalim 6y ago
        Thanks for sharing! Solutions to this problem in the vein of jq and optics were precisely why I started the repo above.
      - bradrn 6y ago
        > This exists (optics/lenses), but most programmers don't know about it. … I don't know of a simple, jargon-free explanation of the concepts. Let me have a go! I’d explain optics/lenses as giving field access as a data structure. That is, a lens is an object which describes how to access an element from a ‘larger’ value. For example, you can define _1 and _2 as lenses for accessing the first and second element respectively of a tuple: _1 :: Lens' (a,b) a _2 :: Lens' (a,b) b (Using Haskell syntax here as that’s what I know best, though I’ve simplified the types slightly.) The great advantage of having these as first-class values is that you can now manipulate them. Of course, the main things you’ll want to do with these are get and set things: > (1,2) ^. _1 1 > (1,2) & _1 .~ 3 (3,2) More interestingly, you can also use a function to modify the value to which a lens is pointing: > (1,2) & _1 %~ negate (-1,2) Most usefully, you can also compose lenses. For instance, to get the second element of the first element of a nested tuple, you can compose _2 and _1 using dot notation: _1._2 :: Lens' ((a,b),c) b Or, for a more realistic example, here’s a lens which accesses the ‘numSeen’ field of the value corresponding to key "keyToIncrement": (ix "keyToIncrement")._numSeen :: Lens' (Map String MyStructure) Int (Well, strictly speaking, this is actually a traversal or a prism or something, because "keyToIncrement" might not exist, but let’s ignore that for this really simple example…) And now that you have it, you can use this new lens to do anything you want with this value: you can get it, set it, increment it, decrement it, print it, etc. Additionally, you don’t have to restrict yourself to just lenses. For example, ‘traversals’ are a generalisation of lenses which allow you to access 0, 1 or more elements, rather than restricting access to just one element at a time. For instance, you can use ‘both’ to transform, well, both elements of a tuple: > (1,2) & both 5~ negate (-1,-2) Or you can use ‘traversed’ to access each element of, say, a list: > [1,2,3,4,5] & traversed .~ 0 [0,0,0,0,0] Of course, there are other ways of doing each of these. If you happen to be working with mutable values, you can sometimes use dot notation to access deeply nested fields. Some usecases of ‘traversed’ can be replaced by a map. However, there really is no comparable substitute for lenses when working with deeply nested immutable structures, especially ones of unknown shape.
arethuza 6y ago
I did a lot of work back in the day with XML, XML Schemas, XSLT etc. I much prefer JSON, JSON Schema even JSON Path (although not used the latter quite as much as the first two). Edit: XSLT could be kind of neat in some contexts if used with a degree of restraint, but it usually wasn't.
rwmj 6y ago
XPath is the real killer feature for parsing XML. I don't think it's possible to use it in this particular example, but in the more generally useful cases where you want to pull (eg) all subnodes with key matching a particular string, XPath is great. Here's it being used in real code (search for "xpath_"): https://github.com/libguestfs/virt-v2v/blob/master/v2v/parse_ovf_from_ova.ml https://github.com/libguestfs/virt-v2v/blob/master/v2v/parse... https://github.com/libguestfs/virt-v2v/blob/master/v2v/parse_libvirt_xml.ml https://github.com/libguestfs/virt-v2v/blob/master/v2v/parse...
- giobox 6y ago
  JSONPath confers pretty much the same concept onto JSON too with much the same syntax. There are JPath implementations for most languages now. > https://github.com/json-path/JsonPath https://github.com/json-path/JsonPath
  - kstrauser 6y ago
    JMESPath is similar: https://jmespath.org https://jmespath.org
mands 6y ago
Couldn't agree more, using the XML toolchain (via lxml in python) for a recent project and it couldn't have gone better - you can get really far quickly with XPath, XSLT, and Relax-NG schemas to ensure correctness. Writing XSLT extensions in python in participate is really powerful.
lifthrasiir 6y ago
I find the very idea of XSLT simply pointless. It is fundamentally structured around templates and doesn't accept anything beyond XML (even in XSLT 3.0, where you can have an initial template but can't get rid of it), making it cumbersome for general programming. It is also very verbose so it is not suitable for scripting as well. For XSLT to be useful you need a complex enough transformation (so you actually want templates) and nothing else (so you can avoid general programming); that use case would be pretty rare.
- nerdponx 6y ago
  Sounds like declarative pattern matching which sounds just great to me [0]. I won't deny that XML sucks to write. But I'm not yet ready to throw the baby out with the bathwater. Maybe we keep using XML as a machine-readable serialization format (and XSLT as serialization of pattern-matching data transformations!) and people use native data structures in their own programming languages. Or we all switch to S-expressions. 0: https://github.com/noprompt/meander https://github.com/noprompt/meander
  - lifthrasiir 6y ago
    Pattern matching is great, but probably not if everything is pattern matching. Also I'm okay with XML as long as it doesn't power an urge to make everything XML and everything connected via the semantic web (lol). XSLT is a remnant of that urge and should have been a non-XML-based language. (The same criticism applies to, e.g. RDF vs. Notation3.)
    - nerdponx 6y ago
      Very good point. Sexprs for all!
quotemstr 6y ago
It's interesting to me how weighty and important technical decisions get made on the basis of the most superficial aesthetic considerations. XML's data model is beautiful, but on a syntactic level, it's kind of ugly, and I think it's mostly for this reason that a certain segment of the industry eschews it even today. Honestly, if XML had kept SGML-style implicit closing tags, we might have never seen the rise of alternative data markup systems. That is, instead of <foo>some_value</foo> you should be able to write (as you can write in SGML) <foo>some_value</> There. Now in exchange for a slight increase in parser complexity, you address a big syntactic wart (the repetition) the drives people away from XML. Seems like a win to me.

by buro9 6y ago

lmm 6y ago

I'm guessing it's because you haven't tried to write an XSLT recently. Yes, it's a way to declarative express transformations which has a lot of elegant theoretical properties. But that doesn't matter when it's so, so painfully tedious to actually write.

saurik 6y ago
XSL/T just kept getting better; like, I agree with exactly what you said for 1.0--which sadly is all libxslt (and thereby browsers that relied on it) ever supported--but XSL/T 2.0 was pretty epic, and there is now even a 3.0 as of a few years ago.
- emmanueloga_ 6y ago
  Agreed, XSLT 3.0 is amazing... and XQuery provides a more palatable syntax, with similar semantics. Kinda ironic that given the problem definition no solution has been provided on XQuery or XSLT yet, the widely used domain specific languages that better suit the problem :-). I believe there's a lot of inspiration to be had from the X-family of languages. The "secret sauce" is XPath. We need a new language drawing inspiration from the tree processing of X* languages but with more modern syntax and less with a less byzantine type system (read: anything but XML Schema :-). Less angle brackets would help too! --- Bonus points: add tuples and prolog like queries to such language (thinking of SPARQL) ... now that would be something really powerful.
  - bmn__ 6y ago
    > We need a new language drawing inspiration This exists (optics/lenses), but most programmers don't know about it. I expect this to hit mainstream programming languages a few years later. I don't know of a simple, jargon-free explanation of the concepts. WP is useless, sadly. http://enwp.org/Bidirectional_transformation http://enwp.org/Bidirectional_transformation Also see: https://news.ycombinator.com/item?id=24710565 https://news.ycombinator.com/item?id=24710565
    - josevalim 6y ago
      Thanks for sharing! Solutions to this problem in the vein of jq and optics were precisely why I started the repo above.
    - bradrn 6y ago
      > This exists (optics/lenses), but most programmers don't know about it. … I don't know of a simple, jargon-free explanation of the concepts. Let me have a go! I’d explain optics/lenses as giving field access as a data structure. That is, a lens is an object which describes how to access an element from a ‘larger’ value. For example, you can define _1 and _2 as lenses for accessing the first and second element respectively of a tuple: _1 :: Lens' (a,b) a _2 :: Lens' (a,b) b (Using Haskell syntax here as that’s what I know best, though I’ve simplified the types slightly.) The great advantage of having these as first-class values is that you can now manipulate them. Of course, the main things you’ll want to do with these are get and set things: > (1,2) ^. _1 1 > (1,2) & _1 .~ 3 (3,2) More interestingly, you can also use a function to modify the value to which a lens is pointing: > (1,2) & _1 %~ negate (-1,2) Most usefully, you can also compose lenses. For instance, to get the second element of the first element of a nested tuple, you can compose _2 and _1 using dot notation: _1._2 :: Lens' ((a,b),c) b Or, for a more realistic example, here’s a lens which accesses the ‘numSeen’ field of the value corresponding to key "keyToIncrement": (ix "keyToIncrement")._numSeen :: Lens' (Map String MyStructure) Int (Well, strictly speaking, this is actually a traversal or a prism or something, because "keyToIncrement" might not exist, but let’s ignore that for this really simple example…) And now that you have it, you can use this new lens to do anything you want with this value: you can get it, set it, increment it, decrement it, print it, etc. Additionally, you don’t have to restrict yourself to just lenses. For example, ‘traversals’ are a generalisation of lenses which allow you to access 0, 1 or more elements, rather than restricting access to just one element at a time. For instance, you can use ‘both’ to transform, well, both elements of a tuple: > (1,2) & both 5~ negate (-1,-2) Or you can use ‘traversed’ to access each element of, say, a list: > [1,2,3,4,5] & traversed .~ 0 [0,0,0,0,0] Of course, there are other ways of doing each of these. If you happen to be working with mutable values, you can sometimes use dot notation to access deeply nested fields. Some usecases of ‘traversed’ can be replaced by a map. However, there really is no comparable substitute for lenses when working with deeply nested immutable structures, especially ones of unknown shape.

arethuza 6y ago

I did a lot of work back in the day with XML, XML Schemas, XSLT etc. I much prefer JSON, JSON Schema even JSON Path (although not used the latter quite as much as the first two). Edit: XSLT could be kind of neat in some contexts if used with a degree of restraint, but it usually wasn't.

rwmj 6y ago

XPath is the real killer feature for parsing XML. I don't think it's possible to use it in this particular example, but in the more generally useful cases where you want to pull (eg) all subnodes with key matching a particular string, XPath is great. Here's it being used in real code (search for "xpath_"): https://github.com/libguestfs/virt-v2v/blob/master/v2v/parse_ovf_from_ova.ml https://github.com/libguestfs/virt-v2v/blob/master/v2v/parse... https://github.com/libguestfs/virt-v2v/blob/master/v2v/parse_libvirt_xml.ml https://github.com/libguestfs/virt-v2v/blob/master/v2v/parse...

giobox 6y ago
JSONPath confers pretty much the same concept onto JSON too with much the same syntax. There are JPath implementations for most languages now. > https://github.com/json-path/JsonPath https://github.com/json-path/JsonPath
- kstrauser 6y ago
  JMESPath is similar: https://jmespath.org https://jmespath.org

mands 6y ago

Couldn't agree more, using the XML toolchain (via lxml in python) for a recent project and it couldn't have gone better - you can get really far quickly with XPath, XSLT, and Relax-NG schemas to ensure correctness. Writing XSLT extensions in python in participate is really powerful.

lifthrasiir 6y ago

I find the very idea of XSLT simply pointless. It is fundamentally structured around templates and doesn't accept anything beyond XML (even in XSLT 3.0, where you can have an initial template but can't get rid of it), making it cumbersome for general programming. It is also very verbose so it is not suitable for scripting as well. For XSLT to be useful you need a complex enough transformation (so you actually want templates) and nothing else (so you can avoid general programming); that use case would be pretty rare.

nerdponx 6y ago
Sounds like declarative pattern matching which sounds just great to me [0]. I won't deny that XML sucks to write. But I'm not yet ready to throw the baby out with the bathwater. Maybe we keep using XML as a machine-readable serialization format (and XSLT as serialization of pattern-matching data transformations!) and people use native data structures in their own programming languages. Or we all switch to S-expressions. 0: https://github.com/noprompt/meander https://github.com/noprompt/meander
- lifthrasiir 6y ago
  Pattern matching is great, but probably not if everything is pattern matching. Also I'm okay with XML as long as it doesn't power an urge to make everything XML and everything connected via the semantic web (lol). XSLT is a remnant of that urge and should have been a non-XML-based language. (The same criticism applies to, e.g. RDF vs. Notation3.)
  - nerdponx 6y ago
    Very good point. Sexprs for all!

quotemstr 6y ago

It's interesting to me how weighty and important technical decisions get made on the basis of the most superficial aesthetic considerations. XML's data model is beautiful, but on a syntactic level, it's kind of ugly, and I think it's mostly for this reason that a certain segment of the industry eschews it even today. Honestly, if XML had kept SGML-style implicit closing tags, we might have never seen the rise of alternative data markup systems. That is, instead of <foo>some_value</foo> you should be able to write (as you can write in SGML) <foo>some_value</> There. Now in exchange for a slight increase in parser complexity, you address a big syntactic wart (the repetition) the drives people away from XML. Seems like a win to me.