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

XML is a cheap DSL

unplannedobsolescence.com

Post reply on HN
Print view View original

191–200 of 274 posts

Re: XML is a cheap DSL

#191

Post by thatwasunusual »

SoftTalker wrote: post #178
thatwasunusual wrote: post #174

Earlier quoted context omitted.

If it's that simple, how come it's so complicated that the US have an entire business line profiting from tax filing?

Most people never look into how simple their situation might be. They just pay TurboTax $50 and move on with their day. But also, taxes can get complicated, I'm just suggesting that for many people, with typical incomes and employment, they are not. When I was in middle school (1970s) we learned how to file a tax return. For some reason this is no longer taught today.

> When I was in middle school (1970s) we learned how to file a tax return. For some reason this is no longer taught today.

We have the same problem in Norway; youngsters aren't taught proper private economy at school, just the "normal maths." Which leads to people getting into financial trouble because of stupid stuff. :/

Thanks for updating me on the US tax system! Hope all is well over there! :)

Re: XML is a cheap DSL

#193

Post by randomNumber7 »

I worked at a place where we had a custom written code generator that used XML as input. It is usable and especially XSD is nice to specify what a valid input file looks like.

On the other hand it is horrible to read and write for humans. Nowadays I would rather use JSON with JSON Schema.

Re: XML is a cheap DSL

#194

Post by gmueckl »

0xbadcafebee wrote: post #184
Someone1234 wrote: post #50

Earlier quoted context omitted.

I keep seeing people make the same mistake as XML made over and over; without learning from it. I will clarify the problem thusly: > The more capabilities you add to a interchange format, the harder that format is to parse. There is a reason why JSON is so popular, it supports so little, that it is legitimately easy to import. Whereas XML supports attributes, namespaces, CDATA, DTDs, QNames, xml:base, xml:lang, XIncl…

The problem is that engineers of data formats have ignored the concept of layers. With network protocols, you make one layer (Ethernet), you add another layer (IP), then another (TCP), then another (HTTP). Each one fits inside the last, but is independent, and you can deal with them separately or together. Each one has a specialty and is used for certain things. The benefits are 1) you don't need "a kitchen sink", 2)…

Some early binary formats followed similar concepts. Look up Interchange File Format, AIFF, RIFF, and their applications and all the file formats using this structure to this day.

Re: XML is a cheap DSL

#195

Post by tannhaeuser »

necovek wrote: post #153
Someone1234 wrote: post #50

Earlier quoted context omitted.

I keep seeing people make the same mistake as XML made over and over; without learning from it. I will clarify the problem thusly: > The more capabilities you add to a interchange format, the harder that format is to parse. There is a reason why JSON is so popular, it supports so little, that it is legitimately easy to import. Whereas XML supports attributes, namespaces, CDATA, DTDs, QNames, xml:base, xml:lang, XIncl…

Funnily enough, XML was an attempt to simplify SGML so it is easier to parse (as SGML only ever had one compliant parser, nsgml).

SGML has at least SP/OpenSP, sgmljs, and nsgml as full-featured, stand-alone parsers. There are also parsers integrated into older versions of products such as MarkLogic, ArborText, and other pre-XML authoring suites, renderers, and CMSs. Then there are language runtime libs such as SWI Prolog's with a fairly complete basic SGML parser.

ISO 8879 (SGML) doesn't define an API or a set of required language features; it just describes SGML from an authoring perspective and leaves the rest to an application linked to a parser. It even uses that term for the original form of stylesheets ("link types", reusing other SGML concepts such as attributes to define rendering properties).

SGML doesn't even require a parser implementation to be able to parse an SGML declaration which is a complex formal document describing features, character sets, etc. used by an SGML document, the idea being that the declaration could be read by a human operator to check and arrange for integration into a foreign document pipeline. Even SCRIPT/VS (part of IBM's DCF and the origin of GML) could thus technically be considered SGML.

There are also a number of historical/academic parsers, and SGML-based HTML parsers used in old web browsers.

Re: XML is a cheap DSL

#198

Post by jancsika »

conartist6 wrote: post #117
GuB-42 wrote: post #103

Earlier quoted context omitted.

I think JSON has the opposite problem, it is too simple, the lack of comments in particular is particularly bad for many common usages of the format today. I know some implementations of JSON support comments and other things, but is is not true JSON, in the same way that most simple XML implementations are not true XML. That's what I say "opposite problem", XML is too complex, and most practical uses of XML use inco…

A lot of people dislike that decision not to include comments in JSON, but I think while shocking it was and is totally correct. In a programming language it's usually free to have comments because the comment is erased before the program runs; we usually render comments in grey text because they can't change the meaning of the program. In a data language you have no such luxury. In a data language there's no comment…

> so comments are just dangerous as they would without doubt evolve into a system of annotations -- an additional layer of communication which would then not be standardized at all and which then would grow into a wild west of nonstandard features and compatibility workarounds

IIRC Douglas Crockford explicitly stated that he saw people initially using comments for a purpose like ad hoc preprocessor directives.

Re: XML is a cheap DSL

#199

Post by zahlman »

conartist6 wrote: post #117
GuB-42 wrote: post #103

Earlier quoted context omitted.

I think JSON has the opposite problem, it is too simple, the lack of comments in particular is particularly bad for many common usages of the format today. I know some implementations of JSON support comments and other things, but is is not true JSON, in the same way that most simple XML implementations are not true XML. That's what I say "opposite problem", XML is too complex, and most practical uses of XML use inco…

A lot of people dislike that decision not to include comments in JSON, but I think while shocking it was and is totally correct. In a programming language it's usually free to have comments because the comment is erased before the program runs; we usually render comments in grey text because they can't change the meaning of the program. In a data language you have no such luxury. In a data language there's no comment…

> In a programming language it's usually free to have comments because the comment is erased before the program runs

That's inherent to the language specification, but it isn't inherent to the document. You have to have a system with rules that require that erasure.

Nothing prevents one from mandating a system that strips those comments out of JSON. You could even "compile" JSON to, I don't know, BSON or msgpack or something.

Just as nothing prevents one from creating tooling to, say, extract type annotations from comments in a dynamically typed language.

Re: XML is a cheap DSL

#200

Post by zahlman »

necovek wrote: post #141
xienze wrote: post #52

Earlier quoted context omitted.

> Whereas XML supports attributes, namespaces, CDATA, DTDs, QNames, xml:base, xml:lang, XInclude, etc etc. They gave it everything, including the kitchen sink. But you don't have to use all those things. Configure your parser without namespace support, DTD support, etc. I'd much rather have a tool with tons of capabilities that can be selectively disabled rather than a "simple" one that requires _me_ to bolt on said…

If you do not go with DTD or XSD, you are only doing XML lookalike language, as these are XML mechanisms to really define the XML schema: a compliant parser won't be able to validate it, or maybe even to parse it. Thus people go with custom parsers (how hard can it be, right?), and then have to keep fixing issues as someone or other submits an XML with CDATA in or similar.

What if we just formalize some reasonable minimal subset, and call it something else?
Post reply on HN