Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SVG: The Good, the Bad and the Ugly

eisfunke.com

Post reply on HN
Print view View original

91–100 of 228 posts

Re: SVG: The Good, the Bad and the Ugly

#91

Post by ognarb »

crazypython wrote: post #86
michaelt wrote: post #63

Earlier quoted context omitted.

> How is XML a garbage fire? If you decided to go fully XML on " " it would probably look like this: 10 10 90 10 90 90 10 90 10 10 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

Alternatively, with SGML:

Same as other commenters, you removed the information about that this coordinate means. Does means I will trace a line to 10,10, move to 10,10, trace a bezier curve, ...

This could be a better format, but still a lot heaver in term of bandwidth.

Re: SVG: The Good, the Bad and the Ugly

#92

Post by hinkley »

cdrini wrote: post #45
simias wrote: post #15

>Furthermore the XML-based syntax is pretty ugly and needlessly verbose. It’s tiring to write by hand and just as tiring to parse or generate automatically. What's even worse is that because XML is a garbage fire of a format, SVG actually builds its own micro-DSL to work around limitations. So for instance you have something like: Ok, fair enough. Readable, self-describing. But then you have: Oh. You can almost hear…

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…

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.

Re: SVG: The Good, the Bad and the Ugly

#93

Post by pwdisswordfish6 »

hinkley wrote: post #84
simias wrote: post #15

>Furthermore the XML-based syntax is pretty ugly and needlessly verbose. It’s tiring to write by hand and just as tiring to parse or generate automatically. What's even worse is that because XML is a garbage fire of a format, SVG actually builds its own micro-DSL to work around limitations. So for instance you have something like: Ok, fair enough. Readable, self-describing. But then you have: Oh. You can almost hear…

> "well fuck it, we'll just jam it all into a string. This is an almost universal disease of people trying to write XML grammars (or database schemas before that). Everyone thinks they can unambiguously decode multiple pieces of data stuffed into the same fixed-width field, and pretty much all of those people are wrong. Over, and over again. That they never learn is a testament to the developer's ability to make fixi…

So one reason for XML failing is that people who nominally used XML didn’t fully use its capabilities to capture data structure and kept their habits from the days of representing all data by fixed-width records?

Re: SVG: The Good, the Bad and the Ugly

#94

Post by Groxx »

crazypython wrote: post #86
michaelt wrote: post #63

Earlier quoted context omitted.

> How is XML a garbage fire? If you decided to go fully XML on " " it would probably look like this: 10 10 90 10 90 90 10 90 10 10 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

Alternatively, with SGML:

This is pretty clearly a more accurate "xml-ification" of a bunch of points. X/Y are un-ordered attributes of a point, not part of an ordered list of things contained within a point.

Re: SVG: The Good, the Bad and the Ugly

#95

Post by Groxx »

mywittyname wrote: post #80
kumarvvr wrote: post #41

Earlier quoted context omitted.

JSON is a really poor format for anything but simple data. XML may be verbose and not readable, but it is an excellent format for describing and storing data. One alternative for SVG could be an SQL table like datastore, similar to sqlite. I would love yo have the ability to query data, rather than parse through XML. I do understand that transferring such data blobs over networks is an issue.

The biggest issue I have with XML is the ambiguity between attributes and child elements. The distinction makes sense in an abstract perspective, but real-world implementations rarely use them in a consistent manner.

One's a dictionary (unordered, simple unique keys), and one's a list (ordered, arbitrary contents, no uniqueness constraints). Schemas may enforce more, but those are the intrinsic qualities.

I agree that use varies widely, but the difference is fairly clear. The existence of nonsense doesn't mean one can't make good decisions.

Re: SVG: The Good, the Bad and the Ugly

#96

Post by wtetzner »

pwdisswordfish6 wrote: post #88
wtetzner wrote: post #85

Earlier quoted context omitted.

> 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?"

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

#97

Post by simias »

runarberg wrote: post #59
cdrini wrote: post #45

Earlier quoted context omitted.

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…

Exactly, in the canvas API this is written like: ctx.moveTo(10, 10); ctx.lineTo(90, 10); ctx.lineTo(90, 90); ctx.lineTo(10, 90); ctx.lineTo(10, 10); Not much better.

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.

Re: SVG: The Good, the Bad and the Ugly

#98

Post by andrey_utkin »

intrepidhero wrote: post #21

> Decide whether a language is for humans or for machines and do one of those things. And do the one thing well instead of both, but badly. The thing is all these languages (ASM, C, XML, JSON, Python, etc) are fundamentally about communication between a human and a machine. We make tradeoffs between making them easy to parse (for the machine) or easy to read and write (for the human) but they all must address both ne…

> fundamentally about communication between a human and a machine.

True! And we should not postulate who is at both sides of the communication - machine or human. It's like postulating that a hammer is a tool which must be held by a human hand, which then precludes robot-operated hammers.

Re: SVG: The Good, the Bad and the Ugly

#99

Post by simias »

goto11 wrote: post #31
simias wrote: post #15

>Furthermore the XML-based syntax is pretty ugly and needlessly verbose. It’s tiring to write by hand and just as tiring to parse or generate automatically. What's even worse is that because XML is a garbage fire of a format, SVG actually builds its own micro-DSL to work around limitations. So for instance you have something like: Ok, fair enough. Readable, self-describing. But then you have: Oh. You can almost hear…

> The fact that SGML-based formats managed to become as popular as they are is really proof that there's something fundamentally rotten in software engineering. HTML is a pretty good syntax though. SGML-like syntax is just less appropriate for formats which are not text-centered, since the element/attribute distinction becomes superfluous noise in the syntax.

I agree, HTML is fine (still a bit too verbose IMO, in particular having to repeat the tag to close it always felt useless and very noisy).

But HTML is a markup language, the problem is that for some insane reason a big chunk of the industry at some point decided that XML was a reasonable serialization format. That's where it went really wrong IMO.

Re: SVG: The Good, the Bad and the Ugly

#100

Post by pwdisswordfish6 »

wtetzner wrote: post #96
pwdisswordfish6 wrote: post #88

Earlier quoted context omitted.

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.

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.

Post reply on HN