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.
Re:SVG: The Good, the Bad and the Ugly
by pwdisswordfish6 on Friday February 12, 2021 @01:16PM
(#26116663)
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.
Except that's not what happened. They also had to define new syntax for the DSLs they embed in strings.
Re:SVG: The Good, the Bad and the Ugly
by pwdisswordfish6 on Friday February 12, 2021 @01:47PM
(#26117005)
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.
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.
Re:SVG: The Good, the Bad and the Ugly
by foolmeonce on Friday February 12, 2021 @02:32PM
(#26117595)
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.
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?"