Repository navigation
Space trimming in dc:title and DCMES optional elements. #1528
Description
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)?
Activity
dauwhe commentedon Feb 25, 2021
See also #1295
iherman commentedon Feb 26, 2021
Yep, indeed. There is a longer discussion on how to define this properly in that issue which we should probably follow.
iherman commentedon Feb 26, 2021
The issue was discussed in a meeting on 2021-02-26
View the transcript
3.2. Trimming leading and following whitespace in package metadata
See github issue #1295, #1528.
Dave Cramer: Let's discuss 1295
… package metadata, according to the spec we need to trim leading and trailing whitespace
… the INFRA spec does have instructions on this
… it would be a step in the right direction to define the trimming as described in the INFRA spec
… this is separate to a discussion on whitespace within the strings
… there is a major RS that ignores this requirement
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
… we can close by referring to it
Dave Cramer: Cool!
… that's all for today
iherman commentedon Mar 3, 2021
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.
mattgarrish commentedon Mar 4, 2021
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.
iherman commentedon Mar 4, 2021
I didn't know that. In this case...
That sounds good. It is then up to the Infra people to get this right!
dauwhe commentedon Mar 4, 2021
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? :)
iherman commentedon Mar 4, 2021
@dauwhe, I was convinced about my own stupidity already :-) (#1528 (comment))