4 ms·

Which keys are mandatory and which are optional? I think that the pictures, long descriptions, web page URLs, and possibly some others, should be optional. It m

Which keys are mandatory and which are optional? I think that the pictures, long descriptions, web page URLs, and possibly some others, should be optional. It might only be a podcast and not a web site. Maybe the FeedURL should also be optional in some blocks; if a LOUD feed program downloads it, and possibly extracts it from the full feed, then it can fill it in if it is omitted. Also, you might want to allow floating numbers for time rather than being limited to integers, since the duration might not be an integer number of seconds. Also, for the list of audio files you might want some way to include the information about quality and file format, as well as to specify the file formats, character encodings, and languages of transcriptions. Again, like the other comment mentions, there will need more description of the formats of some of the string values. The examples help a bit, but examples are not good enough; a proper specification should be needed. Other thing mention in other comments also are issues with this format. I think it isn't good enough, for those and other reasons.

0des 5y ago
Thanks for taking a moment to review the spec > Which keys are mandatory and which are optional? I think that the pictures, long descriptions, web page URLs, and possibly some others, should be optional. It might only be a podcast and not a web site. Maybe the FeedURL should also be optional in some blocks; if a LOUD feed program downloads it, and possibly extracts it from the full feed, then it can fill it in if it is omitted. Optional and required is something that until now had not been considered, but it will be. This is an important point. Thank you. What was meant by "then it can fill it in if it is omitted" this is the only part that was unclear. > Also, you might want to allow floating numbers for time rather than being limited to integers, since the duration might not be an integer number of seconds. Can you elaborate on this? Do you mean a granular measurement more exact than the span of a second? For some context, the reason why it is a number of seconds, currently, is because of the way you can link to a specific timestamp in URLs for audio files using the #t=NNN format, and it works for the most part regardless of which browser clicks the link. This is used in the current implementation of loudreader, a CLI LOUD feed reader with subscriptions. [0] > Also, for the list of audio files you might want some way to include the information about quality and file format, as well as to specify the file formats, character encodings, and languages of transcriptions. This is a good suggestion, thank you. > Again, like the other comment mentions, there will need more description of the formats of some of the string values. The examples help a bit, but examples are not good enough; a proper specification should be needed. This is the part where the most help is needed. All roads point to the need for a formalized spec. That area, or process, is the least familiar unfortunately, though contacts have been made with regard to pursuing this: Jamie Zawinski advised, when asked candidly about the process of making LOUD a standardized spec, that "it's a multi-year process that involves collaborating with a lot of people." which can't be ignored. Currently, the time for that pursuit isn't there, but that's not to say that can't change, which is a big reason behind the MIT license. This is something that is needed, and it can be awesome, but it will take more than 1 person leading the charge, which currently is all that is available. > Other thing mention in other comments also are issues with this format. I think it isn't good enough, for those and other reasons. Thank you for this feedback [0] - https://github.com/loud-feed-format/loudreader https://github.com/loud-feed-format/loudreader

0des 5y ago

Thanks for taking a moment to review the spec > Which keys are mandatory and which are optional? I think that the pictures, long descriptions, web page URLs, and possibly some others, should be optional. It might only be a podcast and not a web site. Maybe the FeedURL should also be optional in some blocks; if a LOUD feed program downloads it, and possibly extracts it from the full feed, then it can fill it in if it is omitted. Optional and required is something that until now had not been considered, but it will be. This is an important point. Thank you. What was meant by "then it can fill it in if it is omitted" this is the only part that was unclear. > Also, you might want to allow floating numbers for time rather than being limited to integers, since the duration might not be an integer number of seconds. Can you elaborate on this? Do you mean a granular measurement more exact than the span of a second? For some context, the reason why it is a number of seconds, currently, is because of the way you can link to a specific timestamp in URLs for audio files using the #t=NNN format, and it works for the most part regardless of which browser clicks the link. This is used in the current implementation of loudreader, a CLI LOUD feed reader with subscriptions. [0] > Also, for the list of audio files you might want some way to include the information about quality and file format, as well as to specify the file formats, character encodings, and languages of transcriptions. This is a good suggestion, thank you. > Again, like the other comment mentions, there will need more description of the formats of some of the string values. The examples help a bit, but examples are not good enough; a proper specification should be needed. This is the part where the most help is needed. All roads point to the need for a formalized spec. That area, or process, is the least familiar unfortunately, though contacts have been made with regard to pursuing this: Jamie Zawinski advised, when asked candidly about the process of making LOUD a standardized spec, that "it's a multi-year process that involves collaborating with a lot of people." which can't be ignored. Currently, the time for that pursuit isn't there, but that's not to say that can't change, which is a big reason behind the MIT license. This is something that is needed, and it can be awesome, but it will take more than 1 person leading the charge, which currently is all that is available. > Other thing mention in other comments also are issues with this format. I think it isn't good enough, for those and other reasons. Thank you for this feedback [0] - https://github.com/loud-feed-format/loudreader https://github.com/loud-feed-format/loudreader