From rfc7990, December 2016 (tools.ietf.org
TL;DL The IAB has switched to XML for making their RFCs so they can
put pretty pictures in them. Merry Christmas and fuck you from Heather
Flanagan, The IETF Team!
When will this normalfag insurgence into the IT field end?
I guess this one will end when you can parse plaintext with less errors than markup.
Would prefer json or, uh
Plaintext ASCII
...
XML is too verbose to be comfortable reading. Even hand-editing XML config files sucks. All they're doing is making stuff more complicated when you could just read ASCII text comfortably.
You guys do understand that XML is not meant to be read by a human? It is meant to be parsed by a computer and then rendered in a format readable by a human.
I don't think XML is a particularly good choice, but it's easier to parse than plain text with some markup rules and it allows readers to just use an XML library to render the RFC to whatever they want, be it HTML, PDF, text in a GUI or plain text in a terminal.
This. XML parsing is a solved problem so it's trivial to use one to extract what you need from an XML document.
XML-to-anything with XSLT
XML is the worst invention to man just because so many things that shouldn't use it are using it.
Why not just, say, LaTeX?
RFCs were designed for reading by human, not computer. It's stupid to use it here, and stupid to encourage more complicated protocol designs than can be described comfortably in plain US-ASCII text files.
This is impressively stupid. The new generation of programmers are cancer.
At least they're using DocBook and not just making up some shitty, non-standard format right? Right?
fucking kill me
Because that would solve the problems they set out to solve.
Right. It's in fact so well and so thoroughly solved, that libxml so (2.9.4) is bigger than glib.
1. Nobody here apparently knows what the fuck SVG is.
2. Nobody here apparently knows that most RFCs are already built as XML and then converted into ASCII, causing no increase in complexity for the vast majority of authors, who already use xml2rfc.
3. Nobody here apparently knows that the purpose of XML is for marking up structured textual data, which RFCs already are.
4. People here literally think that anybody is going to be reading the XML source directly
I hate XML for most purposes, but this is literally the exact domain it was created to handle. How you disappoint me, Holla Forums. Be less fucking stupid, please.
libxml2 is 2.2M
libglib is 1.9M
rapidxml is 148K
expat is 333K
tinyxml is 130K
Quit being intentionally obtuse. libxml is not the only xml parser that exists.
If they're not typing the RFC plain text in vi on OpenBSD, they don't deserve to be on IETF.
That won't markup the semantics of the RFC document, all that does is markup the text layout.
The XML markup implies that it's trivial to transform the document into a format like PDF or HTML.
That's an odd way of spelling ed.
that's an odd way of spelling mov eax, 4mov ebx, 1mov ecx, strmov edx, $lenint 0x80
That's an odd way of toggling the bits with front-panel switches.
Just fucking standardize a version of markdown and use *that*.
Source should always be human readable. IEFT is fucking fucking retarded.
Why do you hate XML and what do you like as an alternative?
That's an odd way of building electromechanical calculating machines
That's an odd way to spell "abacus".
dat odd way to kidnap jew to count shiny rock and rape slaves
Translating Docbook documents (the kind used by the RFC documents) into a format for human reading has already been solved.
I don't see why. Translating ones and zeroes in ASCII encoding is already a solved problem.
Why bother translating into ascii? We should be reading bitstreams of 1's and 0's.
XML isnt that bad if it is well formatted with whitespace. With that said, it rarely is.
I don't hate XML in and of itself. It's a pretty huge format with tons of features that nobody has any use for. Namespaces alone are next to worthless for the vast majority of use-cases, and add useless complexity to the standard. Doctypes are another thing that is essentially useless for almost every single use-case, and entity declaration is similarly pointless. All for a markup format. Individually, these things have some small use in very niche areas, making XML itself a very useful language. These things also make it unbelievably difficult to build a fully compliant XML parser, which is why there are so few (the vast majority of XML parsers that exist are only "mostly" compliant).
The problem is that almost every single use of XML should not be using XML. XML is used in tons of places where it's absolutely unnecessary, because the developers are using it as a config file format, or for serialization, or for IPC, or for simple structured data storage, or (worst of all) user-written input data. All of these would be better off with JSON, YAML, INI, or CSV (maybe even protobuf, capn proto, or msgpack, where binary is appropriate). XML is great, for example, in places where you need to consistently reference large amounts of data (where entity declarations are useful), or where you have a ton of hierarchical data of mixed formats and you absolutely can not afford a name collision. For this reason, XML is fantastic for generated documents (like ODF and DOCX), for text-heavy markup (like XHTML and RFC), and other generated files with tons of stored datatypes where name collision is likely (like GNUCash's files, though a database is better). Tangentially, it's also useful anyplace you might want to apply XSLT.
That's all. I hate XML not because XML itself is bad (it really isn't). I hate XML because it was treated as a panacea in the late 90s and early 00s, and was shoved down everybody's throat like some magic bullet, and now we're stuck with it in dozens of places it doesn't make sense. XML RPC is stupid, SOAP is shit, MusicXML is shit, and so are a ton of other special-purpose formats with limited datatypes that would be better off using almost anything else. If JSON came 5 years earlier we might have been spared. Ironically, the place that XML is absolutely perfect for (the web), it's been almost rejected compared to HTML, so adoption of XHTML has always been way behind, and even now you have to carefully write/generate HTML that happens to be conformant XHTML if you want it to be accepted as both, because writing XHTML that isn't also HTML will make a bunch of shitty browsers choke on it.
The absolutely simplest serialization format/markup language that fits the spec, accounting for possible extension (ie. don't choose something like JSON if you're going to need querying or stylesheet transformations eventually). Usually I use INI/TOML for user-written config format, YAML for user-written that needs more power and saner hierarchies, JSON for computer generated serialization that might need user-reading and writing, and move my way up from MSGPack to protobuf or Capn Proto for anything binary, based on the level of features I might need (Capn Proto since Protobuf 3 did retarded shit with default values, effectively making it impossible to tell whether a field is intentionally a 0 or was unset without a separate enum AND doesn't let you set a different default; Fucking stupid removing features between version 2 and 3).
So in summary, XML isn't bad; the people who use it are bad.
Your face when you find out adobe embedded this crap in all known file formats.
I appreciate the input, user. As an outsider it's been hard to gauge XML, people often say they dislike it or like it but without giving reasons or use cases. I've mainly used INI and JSON in my own programs because the data I'm working with isn't very large in volume or complex in nature so I've never needed anything more yet.
Neat. I've been messing with TCP sockets lately and was considering using msgpack or protobuf for some things, this might be a better fit.
If this is more than an educational venture, consider using proper message queuing, even an in-process one like ZeroMQ or nanomsg.
Building proper framing and message validation, not to mention error handling and recovery, around raw sockets is a bit of pain.