Live data from Hacker News

Relax NG is a schema language for XML (2014)

relaxng.org

21–27 of 27 posts

Re: Relax NG is a schema language for XML (2014)

#21
post #5

Earlier quoted context omitted.

XML as a document markup language was neat imvho. Like, I remember working with DocBook XML[0] and it was fine. And the idea of being able to use different namespaces in a document (think MathML and SVG in XHTML) was neat too. The problems arose from the fact that it was adopted for everything where it largely didn't make much sense. So people came to hate it because e.g. "a functional language to transform XML into…

>And I mean, it's not like SOAP+WSDL actually worked well either, it was always unreliable. I don't think it ever worked. See this [0]. It's pretty crazy that people build one of the most complex and verbose data exchange formats in the world and then it turns out that duplicating the open and close tag and including the parameter name and type in the attributes bought you nothing, because implementations are treatin…

> it's not like SOAP+WSDL actually worked well either, it was always unreliable

This is comparable to saying that "multiplayer distributed architecture at scale" never worked well and was unreliable. All depends what your needs are and how the design and implementation satisfies them. SOAP+WSDL were part or a larger technology vision of Service Oriented Architecture (SOA) with all the complexities of distributed architecture. And the attempt was to make all of that open standards based.

I worked in Print at the time at one of the largest companies (now gone bust), and can confidentally say that SOAP+WSDL worked perfectly for us, and made it way more reliable to tie all these very specialized printing equipment with archaic languages and interfaces together, increasing productivity and efficiency of the entire print process.

Re: Relax NG is a schema language for XML (2014)

#22
post #5
post #3

the compact non-xml syntax is neat: https://relaxng.org/compact-tutorial-20030326.html#id2814005 it reminds me of TypeScript. As for XML itself, it seems like it was a huge buzzword fad in the late 90s/early 2000s, but it must not have lived up to the hype or we’d actually be using it today instead of JSON and Protobuf. I got to computer programming around when the web gave up on XHTML, so i’m not really sure what to…

XML as a document markup language was neat imvho. Like, I remember working with DocBook XML[0] and it was fine. And the idea of being able to use different namespaces in a document (think MathML and SVG in XHTML) was neat too. The problems arose from the fact that it was adopted for everything where it largely didn't make much sense. So people came to hate it because e.g. "a functional language to transform XML into…

I think XML fit well into the turn-of-the-millenium zeitgeist: GUIs would hide the verbosity; the proliferation of bespoke tags would map cleanly to OOP representations; middleware could manipulate and transform data generically, allowing anything to plug into anything else (even over the Internet!).

Whilst lots of impressive things were built, the overall dream was always just out of reach. Domain-specific tooling is expensive to produce and maintain, and often gives something that's not quite what we want (as an extreme example, think of (X)HTML generated by Dreamweaver or FrontPage); generic XML processors/editors don't offer much beyond avoiding syntax/nesting errors; so often it was simplest to interact directly with the markup, where the verbosity, namespacing, normalisation, etc. wouldn't be automated-away.

XML's tree model was also leaky: I've worked with many data formats which look like XML, but actually require various (bespoke!) amounts of preprocessing, templating, dereferencing, etc. which either don't fit the XML model (e.g. graphs or DAGs), or just avoid it (e.g. sprinkling custom grammar like `${foo.bar}` in their text, rather than XML elements like ``). Of course, it was hard to predict how those systems would interact with XML features like namespaces, comments, etc. which made generic processing/transforming middleware less plug-and-play. That, plus billion-laugh mitigation, etc. contributed to a downward spiral of quality, where software would not bother supporting the full generality of XML, and only allowed its own particular subset of functionality, written in one specific way that it expected. That made the processors/transformers even less useful; and so on until eventually we just had a bunch of bespoke, incompatible formats again. At which point, many just threw up their hands and switched to JSON, since at least that was simpler, less verbose and easier to parse... depending whether you support comments... and maybe trailing commas...; or better yet, just stick to YAML. Or TOML.....

(My favourite example: at an old job, I maintained an old server that sent orders from our ecommerce site to third party systems, using a standard "cXML" format. Another team built a replacement for it, I helped them by providing real example documents to test with, and eventually the switch was made. Shortly after, customers were receiving dozens of times what they ordered! It turned out that a third-party was including an XML declaration like `` at the start of their response, which caused the new system to give a parse failure: it treated that as an error, assumed the order had failed, and retried; over and over again!)

Re: Relax NG is a schema language for XML (2014)

#23
post #3

the compact non-xml syntax is neat: https://relaxng.org/compact-tutorial-20030326.html#id2814005 it reminds me of TypeScript. As for XML itself, it seems like it was a huge buzzword fad in the late 90s/early 2000s, but it must not have lived up to the hype or we’d actually be using it today instead of JSON and Protobuf. I got to computer programming around when the web gave up on XHTML, so i’m not really sure what to…

XML is fundamentally incompatible with commonly used programming data structures, namely lists/arrays and structs/maps. That fundamental mismatch caused a lot of friction when people use XML for data exchange between programs. JSON is clear winner here. XML is absolutely fine for data that maps naturally to it. For example text markup. While HTML technically is not XML, it's very close to it and XHTML still is a thin…

"XML is fundamentally incompatible with commonly used programming data structures, namely lists/arrays and structs/maps. That fundamental mismatch caused a lot of friction when people use XML for data exchange between programs. JSON is clear winner here."

I'm not so sure about this. When you have a schema it becomes possible to generate your object code, and then your only immediate interface with the XML file is a rather simple instruction to unmarshal it, the rest of the time you're dabbling within your programming language of choice.

Re: Relax NG is a schema language for XML (2014)

#24
post #19
post #9

Earlier quoted context omitted.

SOAP always seemed to mostly work then if something did fail it was an utter nightmare to work out what the problem was - WSDL really wasn't much fun to read. Whereas when REST APIs came out (using JSON or XML) they were much easier to dive into at the command line with curl and work out how to get things started and diagnose problems when they inevitably came up.

I still cannot tell which one I hate the most: CSV or JSON. These really are hacks that should never have gotten the attention of the world, for data exchange.

At my last job (about 7 years ago) someone treated a tab delimited file as a CSV file and managed to import it into a critical system. It kind of look like it worked but then people noticed that it was actually garbage and there was no obvious way of undoing the import...

Re: Relax NG is a schema language for XML (2014)

#25
post #18
post #17

Earlier quoted context omitted.

I don't think it's a superset. You can represent any structs-and-arrays data in XML, but you have to make non-trivial mappings to make it work. The obvious way is to use elements for everything, but then you're mapping both structs and their fields (very different concepts in e.g. C) to elements. Attributes map nicely to struct fields, but they only admit string values.

That’s why it’s a superset ;) You can map anything to it but that flexibility means you then need to define schemas et al to ensure compliance The schema thing isn’t actually unique to XML either. you can do the same thing with JSON and YAML too. But in my opinion, if you get into the realm of needing schemas in JSON then you’re at the point where you shouldn’t be using JSON any longer since you’re now violating the…

Eh, XML is as much of a superset of JSON as the Turing machine is a superset of context-free grammars. The former has all the _power_ of the latter and more, but the mapping between them is non-trivial, far from an embedding.

I think it's fine to say C#'s data model is a superset of Java's or Rust's a superset of C's, but XML and JSON is too far for me, personally.

Re: Relax NG is a schema language for XML (2014)

#26
post #25
post #18

Earlier quoted context omitted.

That’s why it’s a superset ;) You can map anything to it but that flexibility means you then need to define schemas et al to ensure compliance The schema thing isn’t actually unique to XML either. you can do the same thing with JSON and YAML too. But in my opinion, if you get into the realm of needing schemas in JSON then you’re at the point where you shouldn’t be using JSON any longer since you’re now violating the…

Eh, XML is as much of a superset of JSON as the Turing machine is a superset of context-free grammars. The former has all the _power_ of the latter and more, but the mapping between them is non-trivial, far from an embedding. I think it's fine to say C#'s data model is a superset of Java's or Rust's a superset of C's, but XML and JSON is too far for me, personally.

I didn’t say XML a superset of JSON. I said it’s a superset of common programming abstractions like lists and maps.

This was in response to a comment that said XML was incompatible with such abstractions.

Post reply on HN