Your plain text is less portable than any structured format. You’re creating ad-hoc parsers to process your ad-hoc format. There has to be some implicit structu

Your plain text is less portable than any structured format. You’re creating ad-hoc parsers to process your ad-hoc format. There has to be some implicit structure to this text, otherwise you wouldn’t be able to use lex. All it does is it ties your format to the specific implementation of your parser, including all the bugs in your custom stack. Your logs are now .docs, just in plain text. > It all starts as a stream. That is the "universal format". False. It starts as a data structure in the memory of the producing entity. The most direct or lightweight format would be a direct memory dump of the process. This would be unpractical, so the choice is between a generic portable structured data format and an ad-hoc serialization format. Here’s your pipeline: Structured data (Producer) → Plain text → Structured data (Consumer) It’s like creating JPEGs of your logs and then running OCR to get the structured data back. That would be insane, right? But that’s the exact analogy, just your pipeline is a little lighter. Now consider the alternative: Structured data (Producer) → Portable structured data (.xml) → Structured data (Consumer) The data in a structured, portable and uniform format like XML can be leveraged to offer rich and powerful tools, like XPath/XQuery/XSLT, all the while remaining agnostic to the specific data domain. It’s just the logical thing to do.