-
Notifications
You must be signed in to change notification settings - Fork 61
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Space trimming in dc:title and DCMES optional elements. #1528
Comments
See also #1295 |
Yep, indeed. There is a longer discussion on how to define this properly in that issue which we should probably follow. |
The issue was discussed in a meeting on 2021-02-26
View the transcript3.2. Trimming leading and following whitespace in package metadataSee github issue #1295, #1528. Dave Cramer: Let's discuss 1295 Garth Conboy: What is the proposed change? Dave Cramer: Could it be as simple as linking the word "trim" to the INFRA spec? Ivan Herman: We can normatively refer to the INFRA spec Dave Cramer: Cool! |
This question is still pending (otherwise the issue can be closed by virtue of PR #1539):
My initial take is not to touch this. This may have consequences that we would not really see at this moment. We can re-open this if a real problem/use case comes up. |
Perhaps, but I expect not defining it may also have unintended consequences, too. I'm not sure what breaks if we expect normalization, though, and I recall there are already many checks in epubcheck that normalize values before being able to evaluate/compare them properly. One definition down from trimming in the infra spec is:
https://infra.spec.whatwg.org/#strip-and-collapse-ascii-whitespace Using that in place of just trimming would net the same result for validation of non-empty values and also lead to more consistent strings. |
I didn't know that. In this case...
That sounds good. It is then up to the Infra people to get this right! |
I'm having trouble imagining this. How would an author take advantage of unspecified behavior around collapsing white space inside package metadata? Are people creating libraries of EPUBs with lots of whitespace in book titles and authors in order to create ASCII art with the text of their bookshelves? :) |
@dauwhe, I was convinced about my own stupidity already :-) (#1528 (comment)) |
For dc:title (https://www.w3.org/TR/2021/WD-epub-33-20210224/#sec-opf-dctitle), it is only at the very end of this section that one finds "This specification imposes no additional restrictions or requirements on the title except that it MUST be at least one character in length after white space has been trimmed.."
For DCMES optional elements (https://www.w3.org/TR/2021/WD-epub-33-20210224/#sec-opf-dcmes-optional), the text is just after the formal definition of the elements (the blue box) and slightly different: "The value of all OPTIONAL [DC11] elements MUST be at least one character in length after white space has been trimmed."
Suggestion 1 is to adopt the position and wording of "DCMES optional elements" for "dc:title".
Suggestion 2: I think the intent is that consumers of those elements should trim the white space. Strictly speaking, that is not implied by the text. May be change it to: "Initial and final white space in the value of {this element/all OPTIONAL [DC11] elements} is not significant and there MUST be at least one character in length after white space has been trimmed."
Also: do you intend only trimming of initial and final whitespace, or something more like CSS (e.g. collapsing multiple spaces in the middle)?
The text was updated successfully, but these errors were encountered: