Parsing Epub subjects

[qnga]

Epub Parsing Guide is currently too simplistic about Epub subject parsing.

1. if there is a one single <dc:subject> element, make sure keywords are not separated using commas or semicolons;
   1. if it doesn’t, the string is the value;
   2. if it does, split the string to build an array;
2. if there are more than one <dc:subject> elements, build an array using their values.

Both Readium manifest and Epub supports sortAs and localized strings in subjects, so the algorithm should be modified. I suggest the following:

1. if there is a one single <dc:subject> element without any sorting information or translation (possibly not compliant case), make sure keywords are not separated using commas or semicolons;
   1. if it doesn’t, the string is the value;
   2. if it does, split the string to build an array;
2. else, assume conformance to Epub spec and build an array using their values.

[mickael-menu]

Yes, this sounds like a better strategy.

Current Swift implementation is discarding any sort-as or alternate-script refines as long as there's a single subject, and it contains commas.
https://github.com/readium/r2-streamer-swift/blob/630d8953cbad98fb229233caa9d98b2ce16474b3/r2-streamer-swift/Parser/EPUB/EPUBMetadataParser.swift#L206-L243

But it's safe to assume that if these refines are present, then the commas will be part of the subject name itself and not a separator.

[mickael-menu]

@JayPanoz Do you have an opinion on this subject?

[JayPanoz]

Not really an opinion, perhaps more of a note.

Given the extensiveness of the task of handling refine when first creating this doc, it’s been a strong candidate for improvements through issues, PRs, etc. So it makes perfect sense to me that language is fine-tuned, and I also like the idea of offloading/referring to EPUB spec conformance whenever possible.

Then maybe refine in this doc should be an issue in and of itself, given the handling is currently partial?