7 ms·

Because it was popular, especially in web-development-adjacent circles back then. And there weren’t many open-standard extensible general-purpose structured dat

Because it was popular, especially in web-development-adjacent circles back then. And there weren’t many open-standard extensible general-purpose structured data formats. (There are a few more now, but still not that many.) JSON technically did exist (as a subset of JavaScript), but it wasn’t until Crockford named it that it became widely known. And it’s not like XML has no good ideas in it either. You may disagree about the execution, but the idea of seamlessly mixing structured data defined by independent standards in a single document is pretty damn powerful. Also, your example is rather strawman-ish: there is no point in using separate elements for individual coordinates, and anyone designing the format would know this. A more realistic example would have <path> contain an ordered sequence of <move-to x="..." y="..." /> and <line-to x="..." y="..." /> elements. (In fact, SVG already contains <line /> and <circle /> which use roughly this structure.)

wtetzner 6y ago
> And there weren’t many open-standard extensible general-purpose structured data formats. The thing is, just having an XML parser isn't enough to parse SVG. You also have to parse a DSL. So I think the argument is "why not just use only a DSL, that does a good job of describing the data model?"
- pwdisswordfish6 6y ago
  Because then you’d have to define its syntax and extension points. XML and namespaces solve that problem for you, so the only thing left for you to design is the actual structure of your data.
  - wtetzner 6y ago
    Except that's not what happened. They also had to define new syntax for the DSLs they embed in strings.
    - pwdisswordfish6 6y ago
      True. But it would have been much harder if they had to define a syntax for the entire document. I imagine they thought that the path DSL is simple enough to parse (and I seem to vaguely recall PostScript has something similar), while the overhead of representing path nodes as XML elements would be too high.
      - wtetzner 6y ago
        I'm not arguing against using an existing format, BTW, just seems like a weird mixture here. I can't help but think s-expressions would have been a better choice.
- foolmeonce 6y ago
  I think its relationship with HTML, JavaScript and CSS would be a lot worse if it didn't reuse XML to the extent that it did.
- gugagore 6y ago
  The boundary where the XML ends and the DSL begins is at least a little arbitrary, but it does have important ramifications. By using XML, you can use the XPath query language to index down to a `path` (the end of the XML), but not within a `path` (the beginning of the DSL). That means, at least conceptually, you can attach colors, and events, and such to a path. And the fact that you cannot do it within a path (not without introducing a query language for the DSL) is inelegant, but also might not have much bearing in 99% of applications.
michaelt 6y ago
> Also, your example is rather strawman-ish: there is no point in using separate elements for individual coordinates, and anyone designing the format would know this. You say that - but here's some real world XML from the widely used 'GPX' file format[1] <trkpt lat="47.644548" lon="-122.326897"> <ele>4.46</ele> <time>2009-10-17T18:37:26Z</time> </trkpt> The truth is I could have put the X coordinate as an attribute and the Y coordinate as a child element and it would still have been a fair representation of real-world XML documents. And GPX is one of the better XML formats! You want to see nightmare XML? Go look at SAML. [1] https://en.wikipedia.org/wiki/GPS_Exchange_Format#Sample_GPX_document https://en.wikipedia.org/wiki/GPS_Exchange_Format#Sample_GPX...
- lolinder 6y ago
  These are still examples of crappy DSLs that use XML syntax, not specific problems with XML itself. Designing good DSLs is a hard problem, but is it any less hard in JSON or YAML? If so, it would be helpful for me if people could provide specific examples of why XML itself leads to poor DSLs. As it stands, I'm left wondering if there are so many bad XML DSLs simply because XML is (has been) a popular format.
  - gugagore 6y ago
    Pertinent to this specific discussion is that XML distinguishes syntactically between "elements" and "attributes", but it's often not clear what the purpose of the distinction is (search for "elements vs attributes"). JSON and YAML do not make such a distinction.
    - lolinder 6y ago
      True, but the lack of a clear distinction also seems like a weakness in the specific DSLs rather than a weakness in the format. HTML has (with some exceptions) a very clear distinction between them: attributes are for metadata, elements are for visible page content. Android's XML draws a similar distinction, with attributes used to describe properties of a view and elements used to describe child views. (I do concur with others who have noted here that the "elements" versus "attributes" distinction makes XML a poor choice for serialization, but XML as a serialization format isn't really the issue here.)

wtetzner 6y ago

> And there weren’t many open-standard extensible general-purpose structured data formats. The thing is, just having an XML parser isn't enough to parse SVG. You also have to parse a DSL. So I think the argument is "why not just use only a DSL, that does a good job of describing the data model?"

pwdisswordfish6 6y ago
Because then you’d have to define its syntax and extension points. XML and namespaces solve that problem for you, so the only thing left for you to design is the actual structure of your data.
- wtetzner 6y ago
  Except that's not what happened. They also had to define new syntax for the DSLs they embed in strings.
  - pwdisswordfish6 6y ago
    True. But it would have been much harder if they had to define a syntax for the entire document. I imagine they thought that the path DSL is simple enough to parse (and I seem to vaguely recall PostScript has something similar), while the overhead of representing path nodes as XML elements would be too high.
    - wtetzner 6y ago
      I'm not arguing against using an existing format, BTW, just seems like a weird mixture here. I can't help but think s-expressions would have been a better choice.
foolmeonce 6y ago
I think its relationship with HTML, JavaScript and CSS would be a lot worse if it didn't reuse XML to the extent that it did.
gugagore 6y ago
The boundary where the XML ends and the DSL begins is at least a little arbitrary, but it does have important ramifications. By using XML, you can use the XPath query language to index down to a `path` (the end of the XML), but not within a `path` (the beginning of the DSL). That means, at least conceptually, you can attach colors, and events, and such to a path. And the fact that you cannot do it within a path (not without introducing a query language for the DSL) is inelegant, but also might not have much bearing in 99% of applications.

michaelt 6y ago

> Also, your example is rather strawman-ish: there is no point in using separate elements for individual coordinates, and anyone designing the format would know this. You say that - but here's some real world XML from the widely used 'GPX' file format[1] <trkpt lat="47.644548" lon="-122.326897"> <ele>4.46</ele> <time>2009-10-17T18:37:26Z</time> </trkpt> The truth is I could have put the X coordinate as an attribute and the Y coordinate as a child element and it would still have been a fair representation of real-world XML documents. And GPX is one of the better XML formats! You want to see nightmare XML? Go look at SAML. [1] https://en.wikipedia.org/wiki/GPS_Exchange_Format#Sample_GPX_document https://en.wikipedia.org/wiki/GPS_Exchange_Format#Sample_GPX...

lolinder 6y ago
These are still examples of crappy DSLs that use XML syntax, not specific problems with XML itself. Designing good DSLs is a hard problem, but is it any less hard in JSON or YAML? If so, it would be helpful for me if people could provide specific examples of why XML itself leads to poor DSLs. As it stands, I'm left wondering if there are so many bad XML DSLs simply because XML is (has been) a popular format.
- gugagore 6y ago
  Pertinent to this specific discussion is that XML distinguishes syntactically between "elements" and "attributes", but it's often not clear what the purpose of the distinction is (search for "elements vs attributes"). JSON and YAML do not make such a distinction.
  - lolinder 6y ago
    True, but the lack of a clear distinction also seems like a weakness in the specific DSLs rather than a weakness in the format. HTML has (with some exceptions) a very clear distinction between them: attributes are for metadata, elements are for visible page content. Android's XML draws a similar distinction, with attributes used to describe properties of a view and elements used to describe child views. (I do concur with others who have noted here that the "elements" versus "attributes" distinction makes XML a poor choice for serialization, but XML as a serialization format isn't really the issue here.)