5 ms·

Not about SVG as such, but the XML nature of SVG. I see JSON these days for everything including, for instance, savefiles for documents; templates in Azure, et

by dagss 2y ago

Not about SVG as such, but the XML nature of SVG. I see JSON these days for everything including, for instance, savefiles for documents; templates in Azure, etc etc I wonder if I will honestly, un-ironically, use XML in my next project for something where JSON could have done the job. JSON is missing these small things make it very annoying (mainly comments, comma at end of last element not allowed, and the crappy ambiguities standard vs implementations about numbers, autoformatting of pretty printed JSON not standardized). Also not very readable as config format. And YAML is human editing friendly but so horrible in other ways ( [US, GB, SE, DK, NO, ...]) I am sure there are lots of small competitors. But XML is already there, so well supported everywhere.

mofosyne 2y ago
Something similar to the CBOR diagnostics format but formalized would be nice... since being able to tag semantics would make consistent interpretation of data content easier.
diegof79 2y ago
The problem with XML is that most tools around 2000-2010 used it for everything, including simple configuration files and even DSLs (the Maven v1 XML was a nightmare to maintain). However, there are features of XML that are very useful for a document format like SVG. One of them is namespaces. For example, you can create an SVG and add custom metadata in another namespace, and then any viewer who uses a decent XML parser will show it without issues. That’s not possible with JSON, as there is no guarantee that an unknown key will pass. (although I prefer a simple format like JSON or TOML for config files)
lenkite 2y ago
XML is easier to edit by humans than JSON any-day. SVG is one of the few graphic markup languages whose basics one can pick up in a couple of hours and go to production. If folks object to XML, then they should also object to HTML, JSX, etc. We just need browsers to implement SVG 2.0
- mort96 2y ago
  IMO most of the problem with XML, and the reason why I hate using XML but find JSX and HTML perfectly fine, is that every XML document needs to start with some bullshit like: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> or: <?xml version="1.0" standalone="no"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"> It's not only verbose and extremely ugly but also impossible to remember.
  - deleted 2y ago
    [deleted]
  - deleted 2y ago
    [deleted]
  - lenkite 2y ago
    That old doctype header has been deprecated for ~15 years. You can omit it and need not remember the same. svg header is simply: <svg version="1.1" xmlns="http://www.w3.org/2000/svg"> Maybe read the manual once per decade ? Its like saying JS does not have support for lambdas.
    - mort96 2y ago
      I found them on a website listing the doctors for various XML-based file formats, I didn't realise it was out of date, sorry. Still, that doesn't change anything, my point stands. XML typically has horrible doctypes which are impossible to remember and ugly to look at or parse. I'm not critiquing SVG but XML after all.
      - lenkite 2y ago
        Its one optional line in a header that you don't even need to use if you don't want to. But sure, lets throw out the baby with the bathwater. The fact that JSON cannot have comments is a far more serious drawback than a single line at the top of the document.
mort96 2y ago
I honestly disagree that YAML is human editing friendly, the rules about where the indentations should go is not intuitive. Like when you have a key/value pair where the value is a list, are the dashes indented like this: array: - string one - string two or like this: array: - string one - string two I've found that the easiest way for me to edit YAML (when I have to, which is pretty much exclusively when dealing with CI stuff) is to write it in one of those YAML -> JSON converters online.
- pxeger1 2y ago
  Either of the two examples you gave work.
  - mort96 2y ago
    Then that's a problem in itself: in an indentation based language where more indentation == more deeply nested, allowing multiple levels of indentation to correspond to the same level of nesting is really confusing.
bazoom42 2y ago
The hype curve seem to have run its course and we should prepare for the backlash against JSON. SVG often appears embedded in HTML so it makes sense to have it use similar angle-brackets syntax. Unless they also want to recast HTML in JSON (which I’m sure someone have proposed).

by dagss 2y ago

mofosyne 2y ago

Something similar to the CBOR diagnostics format but formalized would be nice... since being able to tag semantics would make consistent interpretation of data content easier.

diegof79 2y ago

The problem with XML is that most tools around 2000-2010 used it for everything, including simple configuration files and even DSLs (the Maven v1 XML was a nightmare to maintain). However, there are features of XML that are very useful for a document format like SVG. One of them is namespaces. For example, you can create an SVG and add custom metadata in another namespace, and then any viewer who uses a decent XML parser will show it without issues. That’s not possible with JSON, as there is no guarantee that an unknown key will pass. (although I prefer a simple format like JSON or TOML for config files)

lenkite 2y ago

XML is easier to edit by humans than JSON any-day. SVG is one of the few graphic markup languages whose basics one can pick up in a couple of hours and go to production. If folks object to XML, then they should also object to HTML, JSX, etc. We just need browsers to implement SVG 2.0

mort96 2y ago
IMO most of the problem with XML, and the reason why I hate using XML but find JSX and HTML perfectly fine, is that every XML document needs to start with some bullshit like: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> or: <?xml version="1.0" standalone="no"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"> It's not only verbose and extremely ugly but also impossible to remember.
- deleted 2y ago
  [deleted]
- deleted 2y ago
  [deleted]
- lenkite 2y ago
  That old doctype header has been deprecated for ~15 years. You can omit it and need not remember the same. svg header is simply: <svg version="1.1" xmlns="http://www.w3.org/2000/svg"> Maybe read the manual once per decade ? Its like saying JS does not have support for lambdas.
  - mort96 2y ago
    I found them on a website listing the doctors for various XML-based file formats, I didn't realise it was out of date, sorry. Still, that doesn't change anything, my point stands. XML typically has horrible doctypes which are impossible to remember and ugly to look at or parse. I'm not critiquing SVG but XML after all.
    - lenkite 2y ago
      Its one optional line in a header that you don't even need to use if you don't want to. But sure, lets throw out the baby with the bathwater. The fact that JSON cannot have comments is a far more serious drawback than a single line at the top of the document.

mort96 2y ago

I honestly disagree that YAML is human editing friendly, the rules about where the indentations should go is not intuitive. Like when you have a key/value pair where the value is a list, are the dashes indented like this: array: - string one - string two or like this: array: - string one - string two I've found that the easiest way for me to edit YAML (when I have to, which is pretty much exclusively when dealing with CI stuff) is to write it in one of those YAML -> JSON converters online.

pxeger1 2y ago
Either of the two examples you gave work.
- mort96 2y ago
  Then that's a problem in itself: in an indentation based language where more indentation == more deeply nested, allowing multiple levels of indentation to correspond to the same level of nesting is really confusing.

bazoom42 2y ago

The hype curve seem to have run its course and we should prepare for the backlash against JSON. SVG often appears embedded in HTML so it makes sense to have it use similar angle-brackets syntax. Unless they also want to recast HTML in JSON (which I’m sure someone have proposed).