Thanks for commenting, this is the exact type of critical analysis and collaboration that was being sought in posting here. > It's also a bit weird that the ya

Thanks for commenting, this is the exact type of critical analysis and collaboration that was being sought in posting here. > It's also a bit weird that the yaml keys are all lowercase but the other two formats are camel cased That's a good catch, it makes sense that they should match. > You will want to be cautious using string for everything and then trying to define the payload using natural language. Let's take "EpisodeHost []string - List of episode hosts" as a concrete example. Is it their name, email, URL to their IMDb page, does it support html, or (worst case from the perspective of a podcast client implementator) "it depends on the network"? When a field in a spec is string and "do whatever you want", without fail one will find a chocolate chip recipe and an XSS possibly in the same file This is something that is being considered on this end: how do we go about enforcing valid input in each of the fields. In RSS [0] and Atom [1] feeds, it is common to see a mixture of plaintext as well as HTML, depending on which feed you are looking at, and it is up to the parser to present it correctly or whether to render it at all. The "render if desired" quality of the fields seems to be the right mixture of portability for now, but that may change as the protocol is young and implementations are few. One is being worked on, in the form of Loudreader, a CLI feed reader with subscriptions for LOUD. > In that same vein, the fact that FeedURL is singluar but the feed has 3 media types implies that the return type is either negotiated by an Accept header, is chosen by the network provider, or random. That means as a client implementator, I have to immediately support all three parsers with parity out of the gate because I have no means to choose what bytes are sent back. Initially, there was some concern about this and early "builds" of LOUD started out as all JSON, because what you said makes sense, that the dev implementing the client would be prompted to support all 3 in parity to fully support the range of formats that the feed can be presented in. While it is initially slightly more work for someone wanting to implement "the whole protocol", by supporting all 3, it shouldn't be a limiting factor in this day and age when the differences between these formats are so trivial in each language. So far, the biggest difference is a minor complaint that Golang doesnt have a .Valid() for XML or Yaml, which is a personal issue currently. Keep an eye out, this could change, potentially. What are your opinions on this, JSON only soon? > Speaking of bytes, presumably the spec makes the assumption that the file itself is UTF-8 but assumption and standard are at odds with one another Good catch, this wasn't even considered, but will be now that it is mentioned. > I would be surprised if one couldn't extend the Atom spec with these concepts, but I guess the intro section saying it was designed to be more experimental implies that wasn't a consideration This is correct. It is the personal opinion of this developer that without first being part of the legacy Atom community and ingratiating oneself to the nuances behind its current form that "kicking open the door" with hands pressed on hips might be a path of resistance to adoption of the LOUD protocol concept, and would risk the ability to have a holistic realization of the entire spec as it was envisioned. It seemed more polite to create something new. If Atom finds this work beneficial, it would be the highest honor to have any part of it included in any forthcoming revisions to their protocol. [0] - https://cyber.harvard.edu/rss/encodingDescriptions.html https://cyber.harvard.edu/rss/encodingDescriptions.html [1] - https://datatracker.ietf.org/doc/html/rfc4287#section-8.1 https://datatracker.ietf.org/doc/html/rfc4287#section-8.1