I've been trying to get a "best practices" group together for some time.įor RSS, it could publish a proper, humanly-readable specification for best-practice RSS generation. Present, and should contain as many as practical and applicable. Paged feed documents MUST have at least one of these link relations O "next" - A URI that refers to the immediately following document O "previous" - A URI that refers to the immediately preceding O "last" - A URI that refers to the furthest following document in a O "first" - A URI that refers to the furthest preceding document in The feed documents in a paged feed are tied together with the And/or copy the section verbatim as well, as it's literally just four bullet points and two sentences: I suggest to specifically reference section 3 of RFC5005 and provide a succinct example. Section 2 is for marking feeds as complete, which we don't need because there's already a tag for that.Īnd section 4 is for having multiple archives, which isn't usefull for us either. So only a subset, the rest can (should?) be ignored for our purposes. I implement specifically section 3: "Paged Feeds" of the spec. Is it appropriate in any way for us to bake RFC5005 info into this documentation? Perhaps just a section on proper feed archiving that lays things out in a more natural way than an RFC, but basically just says "do it the 5005 way." Until then, the main podcast feed (/ first page) needs to contain all episodes. It's only really useful once adoption is high, in either case. Maybe even 5 would be enough eventually.įurthermore, creating a new standard wouldn't be more or less backwards compatible. My gut says 10 but I can't really put solid arguments behind it. What we should think about though is a recommended number of episodes on the first feed page for the hypothetical state of good-enough adoption of the standard. As says, in the transition period, podcasters must include a higher number of episodes on the first podcast page - just as they do now. It is backwards compatible: clients that don't read the RFC5005 tags can ignore them. Actually, I think the better way I should have brought this up is emphasizing the need for backwards compatibility.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |