13 ms·

How is XML a garbage fire? In comparison to what? Also, representing paths succinctly as text is inherently complicated. You're trying to represent a very 2D th

by cdrini 6y ago

How is XML a garbage fire? In comparison to what? Also, representing paths succinctly as text is inherently complicated. You're trying to represent a very 2D thing in a linear 1D syntax. It's not a limitation of XML, it's a limitation of text being 1D. XML/SGML are a very effective way of representing tree data (again, non-1D data) in 1D strings. And they're wonderfully extensible, while still keeping a well defined schema. Is there an alternative language that is better? How is it better?

runarberg 6y ago
Exactly, in the canvas API this is written like: <path d="M 10 10 H 90 V 90 H 10 L 10 10"/> ctx.moveTo(10, 10); ctx.lineTo(90, 10); ctx.lineTo(90, 90); ctx.lineTo(10, 90); ctx.lineTo(10, 10); Not much better.
- simias 6y ago
  I disagree, the JS code is immediately understandable without having to lookup anything. You could do it in pure XML but the result would probably be much more verbose.
  - runarberg 6y ago
    To be equivalent the SVG `<path>` element would probably need to take an idref to something like a `<draw>` element. This is how I would guess the equivalent would be: <draw id="my-path"> <move-to x="10" y="10" /> <line-to x="90" y="10" /> <line-to x="90" y="90" /> <line-to x="10" y="90" /> <line-to x="10" y="10" /> </draw> <path draw="my-path" /> EDIT: Come to think of it, the above is probably a lot easier to animate using CSS or SMIL. Animating the `d` attribute on `<path>`s is theoretically possible but in practice weird at best or browser inconsistent or simply impossible at worst. EDIT 2: In D3 it is not uncommon to draw area graphs with a thick border on top. The only way to do this is with two `<path>`s with almost identical `d` attributes. Allowing drawings to be strung together with multiple idrefs could solve that: <draw id=line-path></draw> <draw id="area-box-close"> <line-to x="100" y="100" /> <line-to x="0" y="100" /> <end /> </draw> <path draw="line-path" class="line" /> <path draw="line-path area-box-close" class="area" /> Maybe this isn’t such a bad idea after all.
    - simias 6y ago
      Yes! That's a lot better IMO, but I suspect that the reason for the custom string with single letter "operators" is because the size overhead was unbearable for SVGs with complex paths (which, being a vector format, should be considered the baseline). The overhead is already pretty massive with the current spec, gzipped you can usually divide the file size by an order of magnitude. I SVG is pretty inelegant, but it's pragmatical.
  - cdrini 6y ago
    I would argue that using something like this would result in a less readable file overall. 85% of people editing SVGs by hand have 0 interest in modifying paths by hand. They likely want to move elements around, change groups, etc. If the d-path was written less compactly, these path definitions, which, again most people don't even care about, would end up taking up the vast majority of the space in the file. It would be impossible to get an idea of the nesting, and super annoying to move things around since they would be huge. Also: Reminder SVGs goal is presentation, so paths even for a simple monochrome icon have _hundreds_ of control points. Something more intricate or a larger graphic? Thousands easily. All the examples here are toy examples, that don't scale to what SVG is actually used for.
eek04_ 6y ago
Tagged interchange formats like https://en.wikipedia.org/wiki/Interchange_File_Format https://en.wikipedia.org/wiki/Interchange_File_Format were IMO much better to work with than XML from a programming point of view. If I want something free-form text based, I've been more happy with e.g. YAML based formats.
michaelt 6y ago
> How is XML a garbage fire? If you decided to go fully XML on "<path d="M 10 10 H 90 V 90 H 10 L 10 10"/>" it would probably look like this: <path> <point> <x>10</x> <y>10</y> </point> <point> <x>90</x> <y>10</y> </point> <point> <x>90</x> <y>90</y> </point> <point> <x>10</x> <y>90</y> </point> <point> <x>10</x> <y>10</y> </point> </path> Some would say the fact the designers of XML went for "M 10 10 H 90 V 90 H 10 L 10 10" instead shows they thought XML is too verbose. simias likely agrees that XML is too verbose - and wonders why they used XML at all
- pwdisswordfish6 6y ago
  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.
hinkley 6y ago
The presentations/articles on how to unambiguously decode the XML Signature Spec are almost as long as the spec itself. When it was my turn to parse it, I found a couple of cases they missed. In XML ID fields are supposed to be unique to the document. Nobody enforces this. Instead getByID returns the first ID. Which means if you ask a DOM element and the root element for an element by ID, you can get two different answers. Composing multiple schemas into the same file is a wordy, confusing mess, DTDs are straight up broken, and the only time I ever saw someone generate a Grade A XML Schema was by feeding examples into XMLSpy instead of writing their own. XML asks a question we already knew the answer to: What if we made everyone into a programming language designer? And the answer was "anarchy" because we know that many people cannot design a syntactically consistent language, and hardly anybody can design a semantically consistent one. James Strachan, as I recall, retired from Groovy before they ever figured out an unambiguous grammar for it. There comes a point where you realize you've made a mess that you are not qualified to clean up (Kernighan's Law). You can either do the very hard work of maturing into the responsibility, or bow out. Strachan is no different than a dozen people I've worked with and countless people I've heard about second or third hand, who I'm more than a little glad moved on. The guilt is not theirs alone. Part must fall to this shared delusion that you can do anything with software if you only put your mind to it. We have mathematical proofs that tell us that's not true, and yet we still believe in the power of belief. Unfortunately if we didn't believe it a little, then we'd probably never write anything at all, so I'm not sure there's so much a cure as a condition that has to be managed. A little bit can go a long way, and most of us take it too far, sooner or later.
simias 6y ago
SGML (and descendants) is a markup language. It's in the name really. >XML/SGML are a very effective way of representing tree data Completely disagree: - It's not effective density-wise because the format is very verbose - It's not effective parsing-wise because the format is very complicated. - It's not effective human-wise because you have meaningless distinctions between attributes and child nodes which makes sense for a markup language but not for a serialization format. It's also very verbose which makes it annoying to read and write. Imagine that you have an object like: struct Object { name: "foo", } Should you serialize like: <object name="foo" /> Or: <object> <name>foo</name> </object> And to be clear, that's a rhetorical question. My point is that this distinction doesn't make a lot of sense for a serialization format and forces the developer to make pointless decisions. Here you might say that an attribute makes more sense, but then if later you realize that you can have several names you're screwed, because you either have to come up with your own custom format to store those in an attribute (coma-separated? But what if there's a coma in the name?) or split them off into child nodes. It makes perfect sense for a markup language though, because there's (usually) a clear distinction between the textual and metatextual content. The stuff between the tags is meant to be displayed to the user, whereas the attributes are meant to be interpreted by the machine.
- DonHopkins 6y ago
  Actually it's not a pointless distinction. If you care about the integrity of your string, you'd better use text nodes with CDATA, not attributes, because of the dreaded obscure XML feature called "Attribute Value Normalization". XML just tempts you to use attributes to represent strings, then kicks you in the ass when you least expect it by corrupting your data unexpectedly and unfairly but with full legal authority of the xml standard itself. I wrote about it in this other comment: https://news.ycombinator.com/item?id=26122107 https://news.ycombinator.com/item?id=26122107
- cdrini 6y ago
  Agreed; XML is best for document trees more than just generic tree data in general. I think the meaning between attributes/child nodes is pretty clear for like ~85% of use cases. Namely: attributes are for properties of the current node, child nodes are separate elements which are contained in the current node. I agree it can be complicated to parse, and don't agree it's exceptionally verbose. It is more verbose than say, a CSV or something, or than JSON (only because of the ending tags), but I wouldn't call it exceptionally verbose. That verbosity often makes things easier to read to than e.g. JSON, where you need a `type: "paragraph"` or equivalent on every element to simulate how HTML works. XML is better for document trees, JSON is better for generic tree data. (Note: XAML does have a nice duality between attributes and nodes (sort of) which is kind of interesting. It's been a while since I've used it though, so can't quite recall the details).

by cdrini 6y ago

runarberg 6y ago

Exactly, in the canvas API this is written like: <path d="M 10 10 H 90 V 90 H 10 L 10 10"/> ctx.moveTo(10, 10); ctx.lineTo(90, 10); ctx.lineTo(90, 90); ctx.lineTo(10, 90); ctx.lineTo(10, 10); Not much better.

simias 6y ago
I disagree, the JS code is immediately understandable without having to lookup anything. You could do it in pure XML but the result would probably be much more verbose.
- runarberg 6y ago
  To be equivalent the SVG `<path>` element would probably need to take an idref to something like a `<draw>` element. This is how I would guess the equivalent would be: <draw id="my-path"> <move-to x="10" y="10" /> <line-to x="90" y="10" /> <line-to x="90" y="90" /> <line-to x="10" y="90" /> <line-to x="10" y="10" /> </draw> <path draw="my-path" /> EDIT: Come to think of it, the above is probably a lot easier to animate using CSS or SMIL. Animating the `d` attribute on `<path>`s is theoretically possible but in practice weird at best or browser inconsistent or simply impossible at worst. EDIT 2: In D3 it is not uncommon to draw area graphs with a thick border on top. The only way to do this is with two `<path>`s with almost identical `d` attributes. Allowing drawings to be strung together with multiple idrefs could solve that: <draw id=line-path></draw> <draw id="area-box-close"> <line-to x="100" y="100" /> <line-to x="0" y="100" /> <end /> </draw> <path draw="line-path" class="line" /> <path draw="line-path area-box-close" class="area" /> Maybe this isn’t such a bad idea after all.
  - simias 6y ago
    Yes! That's a lot better IMO, but I suspect that the reason for the custom string with single letter "operators" is because the size overhead was unbearable for SVGs with complex paths (which, being a vector format, should be considered the baseline). The overhead is already pretty massive with the current spec, gzipped you can usually divide the file size by an order of magnitude. I SVG is pretty inelegant, but it's pragmatical.
- cdrini 6y ago
  I would argue that using something like this would result in a less readable file overall. 85% of people editing SVGs by hand have 0 interest in modifying paths by hand. They likely want to move elements around, change groups, etc. If the d-path was written less compactly, these path definitions, which, again most people don't even care about, would end up taking up the vast majority of the space in the file. It would be impossible to get an idea of the nesting, and super annoying to move things around since they would be huge. Also: Reminder SVGs goal is presentation, so paths even for a simple monochrome icon have _hundreds_ of control points. Something more intricate or a larger graphic? Thousands easily. All the examples here are toy examples, that don't scale to what SVG is actually used for.

eek04_ 6y ago

Tagged interchange formats like https://en.wikipedia.org/wiki/Interchange_File_Format https://en.wikipedia.org/wiki/Interchange_File_Format were IMO much better to work with than XML from a programming point of view. If I want something free-form text based, I've been more happy with e.g. YAML based formats.

michaelt 6y ago

> How is XML a garbage fire? If you decided to go fully XML on "<path d="M 10 10 H 90 V 90 H 10 L 10 10"/>" it would probably look like this: <path> <point> <x>10</x> <y>10</y> </point> <point> <x>90</x> <y>10</y> </point> <point> <x>90</x> <y>90</y> </point> <point> <x>10</x> <y>90</y> </point> <point> <x>10</x> <y>10</y> </point> </path> Some would say the fact the designers of XML went for "M 10 10 H 90 V 90 H 10 L 10 10" instead shows they thought XML is too verbose. simias likely agrees that XML is too verbose - and wonders why they used XML at all

pwdisswordfish6 6y ago
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.

hinkley 6y ago

The presentations/articles on how to unambiguously decode the XML Signature Spec are almost as long as the spec itself. When it was my turn to parse it, I found a couple of cases they missed. In XML ID fields are supposed to be unique to the document. Nobody enforces this. Instead getByID returns the first ID. Which means if you ask a DOM element and the root element for an element by ID, you can get two different answers. Composing multiple schemas into the same file is a wordy, confusing mess, DTDs are straight up broken, and the only time I ever saw someone generate a Grade A XML Schema was by feeding examples into XMLSpy instead of writing their own. XML asks a question we already knew the answer to: What if we made everyone into a programming language designer? And the answer was "anarchy" because we know that many people cannot design a syntactically consistent language, and hardly anybody can design a semantically consistent one. James Strachan, as I recall, retired from Groovy before they ever figured out an unambiguous grammar for it. There comes a point where you realize you've made a mess that you are not qualified to clean up (Kernighan's Law). You can either do the very hard work of maturing into the responsibility, or bow out. Strachan is no different than a dozen people I've worked with and countless people I've heard about second or third hand, who I'm more than a little glad moved on. The guilt is not theirs alone. Part must fall to this shared delusion that you can do anything with software if you only put your mind to it. We have mathematical proofs that tell us that's not true, and yet we still believe in the power of belief. Unfortunately if we didn't believe it a little, then we'd probably never write anything at all, so I'm not sure there's so much a cure as a condition that has to be managed. A little bit can go a long way, and most of us take it too far, sooner or later.

simias 6y ago

SGML (and descendants) is a markup language. It's in the name really. >XML/SGML are a very effective way of representing tree data Completely disagree: - It's not effective density-wise because the format is very verbose - It's not effective parsing-wise because the format is very complicated. - It's not effective human-wise because you have meaningless distinctions between attributes and child nodes which makes sense for a markup language but not for a serialization format. It's also very verbose which makes it annoying to read and write. Imagine that you have an object like: struct Object { name: "foo", } Should you serialize like: <object name="foo" /> Or: <object> <name>foo</name> </object> And to be clear, that's a rhetorical question. My point is that this distinction doesn't make a lot of sense for a serialization format and forces the developer to make pointless decisions. Here you might say that an attribute makes more sense, but then if later you realize that you can have several names you're screwed, because you either have to come up with your own custom format to store those in an attribute (coma-separated? But what if there's a coma in the name?) or split them off into child nodes. It makes perfect sense for a markup language though, because there's (usually) a clear distinction between the textual and metatextual content. The stuff between the tags is meant to be displayed to the user, whereas the attributes are meant to be interpreted by the machine.

DonHopkins 6y ago
Actually it's not a pointless distinction. If you care about the integrity of your string, you'd better use text nodes with CDATA, not attributes, because of the dreaded obscure XML feature called "Attribute Value Normalization". XML just tempts you to use attributes to represent strings, then kicks you in the ass when you least expect it by corrupting your data unexpectedly and unfairly but with full legal authority of the xml standard itself. I wrote about it in this other comment: https://news.ycombinator.com/item?id=26122107 https://news.ycombinator.com/item?id=26122107
cdrini 6y ago
Agreed; XML is best for document trees more than just generic tree data in general. I think the meaning between attributes/child nodes is pretty clear for like ~85% of use cases. Namely: attributes are for properties of the current node, child nodes are separate elements which are contained in the current node. I agree it can be complicated to parse, and don't agree it's exceptionally verbose. It is more verbose than say, a CSV or something, or than JSON (only because of the ending tags), but I wouldn't call it exceptionally verbose. That verbosity often makes things easier to read to than e.g. JSON, where you need a `type: "paragraph"` or equivalent on every element to simulate how HTML works. XML is better for document trees, JSON is better for generic tree data. (Note: XAML does have a nice duality between attributes and nodes (sort of) which is kind of interesting. It's been a while since I've used it though, so can't quite recall the details).