5 ms·
> 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. Y
by 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 agoBecause 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 agoExcept that's not what happened. They also had to define new syntax for the DSLs they embed in strings.
- pwdisswordfish6 6y agoTrue. 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 agoI'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 agoI 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 agoThe 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.