Content-Length: 300274 | pFad | https://github.com/w3c/epub-specs/issues/1528

E9 Space trimming in dc:title and DCMES optional elements. · Issue #1528 · w3c/epub-specs · GitHub
Skip to content
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

Closed
emuller-amazon opened this issue Feb 25, 2021 · 8 comments · Fixed by #1557
Closed

Space trimming in dc:title and DCMES optional elements. #1528

emuller-amazon opened this issue Feb 25, 2021 · 8 comments · Fixed by #1557
Labels
Cat-ReadingSystemConformance Grouping label for all issues that affect reading system conformance EPUB33 Issues addressed in the EPUB 3.3 revision Spec-ReadingSystems The issue affects the EPUB Reading Systems 3.3 Recommendation Topic-PackageDoc The issue affects package documents

Comments

@emuller-amazon
Copy link

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)?

@dauwhe
Copy link
Contributor

dauwhe commented Feb 25, 2021

See also #1295

@dauwhe dauwhe added Cat-ReadingSystemConformance Grouping label for all issues that affect reading system conformance Spec-ReadingSystems The issue affects the EPUB Reading Systems 3.3 Recommendation labels Feb 25, 2021
@mattgarrish mattgarrish added the Topic-PackageDoc The issue affects package documents label Feb 25, 2021
@iherman
Copy link
Member

iherman commented Feb 26, 2021

See also #1295

Yep, indeed. There is a longer discussion on how to define this properly in that issue which we should probably follow.

@iherman
Copy link
Member

iherman commented Feb 26, 2021

The issue was discussed in a meeting on 2021-02-26

  • no resolutions were taken
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
Copy link
Member

iherman commented Mar 3, 2021

This question is still pending (otherwise the issue can be closed by virtue of PR #1539):

Do you intend only trimming of initial and final whitespace, or something more like CSS (e.g. collapsing multiple spaces in the middle)?

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
Copy link
Member

mattgarrish commented Mar 4, 2021

This may have consequences that we would not really see at this moment.

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:

To strip and collapse ASCII whitespace in a string, replace any sequence of one or more consecutive code points that are ASCII whitespace in the string with a single U+0020 SPACE code point, and then remove any leading and trailing ASCII whitespace from that string.

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
Copy link
Member

iherman commented Mar 4, 2021

This may have consequences that we would not really see at this moment.

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.

I didn't know that. In this case...

One definition down from trimming in the infra spec is:

To strip and collapse ASCII whitespace in a string, replace any sequence of one or more consecutive code points that are ASCII whitespace in the string with a single U+0020 SPACE code point, and then remove any leading and trailing ASCII whitespace from that string.

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.

That sounds good. It is then up to the Infra people to get this right!

@dauwhe
Copy link
Contributor

dauwhe commented Mar 4, 2021

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.

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
Copy link
Member

iherman commented Mar 4, 2021

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.

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))

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Cat-ReadingSystemConformance Grouping label for all issues that affect reading system conformance EPUB33 Issues addressed in the EPUB 3.3 revision Spec-ReadingSystems The issue affects the EPUB Reading Systems 3.3 Recommendation Topic-PackageDoc The issue affects package documents
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants








ApplySandwichStrip

pFad - (p)hone/(F)rame/(a)nonymizer/(d)eclutterfier!      Saves Data!


--- a PPN by Garber Painting Akron. With Image Size Reduction included!

Fetched URL: https://github.com/w3c/epub-specs/issues/1528

Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy