On Tuesday, October 26, 2021 at 6:51:56 AM UTC-5 Philip McGrath wrote:

> I'm not totally clear about all of the different sets of requirements 
> (RSS, Atom, and, de facto, Apple), but I thought there were more language 
> codes permitted than ISO 639-1 (e.g. 
> https://www.rssboard.org/rss-language-codes points to ISO 639-2, and 
> https://validator.w3.org/feed/docs/rfc4287.html#rfc.section.4.2.7.4 for 
> Atom points to RFC 3066. These standards also allow for the assignment of 
> new codes (and, at least for ISO 639-3, deprecation). I hope the right set 
> of codes might be in the one of the CLDR packages (also used by Gregor): if 
> so, I'd recommend getting it from there.
>

We could probably open it up to more codes for generic feeds, for sure. 
Podcast feeds are limited to ISO 639-1 by Apple. Also, system language 
detection would probably always be limited to ISO 639-1 for the foreseeable 
future, unless I find out that my existing method might encounter (and 
mis-handle) codes from other lists in some circumstances.
 

> On a different topic, for the XML stuff, is there a requirement that 
> embedded HTML be represented with the CDATA lexical syntax? 
>

I’m using CDATA for the traditional reason: it allowed me to punt on 
validating the internal content. If I didn’t use CDATA, I’d probably want 
to start handling strings and tagged xexprs differently. Strings would go 
in as `<content type="text">` and an exception should probably be raised if 
it can be determined (how?) that the string is actually a string of HTML. 
Tagged X-exprs would go in as `<content type="html">` with escaped HTML as 
you suggest. Or perhaps only tagged x-expressions should be allowed. Or 
perhaps strings should be coerced to a txexpr (by, e.g. putting them inside 
a 'div).
 

> everyone manipulating these feeds in Racket 
>

Although I make this possible, the design intent is that once you put stuff 
into a food-like struct, that’s the last step before generating the final 
feed (thus keeping all the guarantees of validation intact). I would hope 
that *content* in particular would not need more manipulation between the 
creation of a feed-item struct and the final output.
 

> (Tangentially, AIUI the convention is to use `#f` for the start and stop 
> fields when creating cdata and p-i structures in code, though apparently the 
> docs for `source` 
> <https://docs.racket-lang.org/xml/index.html#%28def._%28%28lib._xml%2Fmain..rkt%29._source%29%29>
>  
> say something about symbols.)
>

Indeed, since the structures returned by xexpr->xml use 'racket for those 
fields, I though mine ought to match.
 

> rather than using an ad-hoc encoding scheme for the entities Apple has odd 
> rules about, you can just replace them with symbols or `valid-char?`s and 
> let the library take care of everything. Well, my example code for that has 
> grown complete enough that I'll just make a PR shortly :)
>

Sounds good! Just bear in mind that Apple is not only picky about the 
characters it wants replaced but also about what you replace them with. 
E.g. &#xA9; and not &copy; for the copyright symbol. 

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/5b83ad5f-3be1-4bd7-a876-0184dafadbddn%40googlegroups.com.

Reply via email to