Repository navigation
Trimming leading and following whitespace in package metadata #1295
Description
The packages spec says the following many, many times about almost all the metadata in the OPF file:
Reading Systems MUST trim all leading and trailing white space [XML] before processing the value.
Inconveniently, the word "trim" does not appear in the XML 1.0 spec.
Conveniently, it turns out that WHATWG has a infrastructure spec (who knew?) that actually has a definition of this
To strip leading and trailing ASCII whitespace from a string, remove all ASCII whitespace that are at the start or the end of the string.
I wonder if we should improve our definition.
Incidentally, it appears many reading systems ignore this. I wrote a test this afternoon...
Activity
danielweck commentedon Sep 10, 2019
... and this should probably apply consistently to metadata attribute values, as well as element content (text child node), right?
Another interesting parsing rule is whitespace collapsing (space characters, tabs, etc. merged into a single space) inside strings, after leading and trailing whitespace has been removed. This would typically be needed for long textual descriptions, which may span across multiple lines, with indentation (i.e. "insignificant" whitespace).
So, how much of that is purely down to de-facto XML string normalization rules (in other words, reading system implementations just use whatever text the XML parser returns), vs. an additional layer of parsing rules, defined by the EPUB specification?
dauwhe commentedon Sep 10, 2019
At least one major reading system does not collapse whitespace within metadata, even just plain runs of U+0020.
rdeltour commentedon Sep 13, 2019
@dauwhe
I think the XML reference is for the definition of white space, not for trim.
Yes, it would be a good clarification IMO.
Note that the ASCII whitespace definition in the Infra standard differs from the white space definition in XML in that the former includes the form feed character (U+000C) when the latter does not. But this is OK since control characters are disallowed in well-formed XML 1.0 documents anyways.
@danielweck
I think the question is about the clarification of what is meant by
trim. The rules defining whether to strip whitespace or not would still be defined for each element and attribute (as they are in 3.2).In HTML this isn’t done at parsing time but when building the render tree (this is why for instance the
white-space: preCSS property can work).But yes, in Package Doc metadata we could possibly introduce white space collapsing rules in the white space handling algorithms (which currently only consist in stripping the leading/trailing whitespace).
without any whitespace handling rules defined schemas (which are not normative in EPUB), XML by default say to preserve all the whitespace; so all the handling has to be explicitly described in the EPUB specification.
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