Re: Looking for some clarification

Thanks Matt,

Fresh eyes :-)

JF

On Thu, Jul 29, 2021 at 2:30 PM Matt Garrish <matt.garrish@gmail.com> wrote:

> > rereading this and I now understand that only section D.8.1 is
> non-normative … it was a nuance that I missed on first read
>
>
>
> Ah, the subsection labels again! We wrote out some of these sections
> earlier this revision in the package vocabularies to avoid a similar kind
> of issue, as I recall.
>
>
>
> We could probably do the same here and merge the paragraphs under the
> Structural Semantics heading to get rid of that subsection (and label), as
> all the other “About this vocabulary” sections are now gone. I’ll open an
> issue to fix this.
>
>
>
> Thanks!
>
>
>
> Matt
>
>
>
> *From:* John Foliot <john@foliot.ca>
> *Sent:* July 29, 2021 2:18 PM
> *To:* Matt Garrish <matt.garrish@gmail.com>
> *Cc:* John Foliot <john@foliot.ca>; W3C EPUB 3 Working Group <
> public-epub-wg@w3.org>; Avneesh Singh <avneesh.sg@gmail.com>; Ivan Herman
> <ivan@w3.org>
> *Subject:* Re: Looking for some clarification
>
>
>
> Matt and Tzviya,
>
>
>
> Thank you, this is most helpful. Matt, to your last question, I apologize
> in that I saw this:
>
> D.8 Structural Semantics Vocabulary
> D.8.1 About this Vocabulary
>
> *This section is non-normative.*
>
> ...and got ahead of myself - rereading this and I now understand that only
> section D.8.1 is non-normative; D.8.2 through D.8.19 are not tagged as
> non-normative (so, ergo, normative), but it was a nuance that I missed on
> first read. As simply a suggestion, perhaps moving that around a bit may
> help (but not a hill to die on):
>
> D.8 Structural Semantics Vocabulary
> Note: Section D.8.1 is non-normative, all other sections are normative.
>
> D.8.1 About this Vocabulary
> (...just a thought: if I missed it, it's possible others might as well...)
>
>
>
> JF
>
>
>
> On Thu, Jul 29, 2021 at 12:39 PM Matt Garrish <matt.garrish@gmail.com>
> wrote:
>
> Hi John,
>
>
>
> > Looking specifically at usage in <nav epub:type="landmarks">, is there a *minimum
> set* or collection of landmark-values expected in a publication?
>
>
>
> No. We’ve looked at this issue in the past, but the landmarks are for
> reading system use and there’s no requirement that reading systems
> implement any functionality based on landmarks. I believe the only
> behaviour that’s been documented as having some uptake is including a link
> with epub:type=bodymatter so that reading systems can automatically skip
> the front matter when opening a publication. But that’s not universal and
> not something we’d want to enforce now.
>
>
>
> > I am *presuming* that the Partition value (actually, any epub:type's
> value) should also use a "Human Readable" label (accessible name),
>
>
>
> It would be helpful if the links were exposed to users, yes, but the
> landmarks links are the more central part. The original idea was that the
> reading system could use these links to implement its UI (e.g., have a
> dedicated button to open a glossary or index), so the text of the links
> would most likely be discarded to provide a consistent interface. Listing
> all kinds of general content destinations in the landmarks for users is
> largely redundant with the table of contents.
>
>
>
> > *Document Partitions* vs. *Document Sections and Components*, does one
> category have stronger or more important semantics in practical usage?
>
>
>
> Front, body and back matter are conceptual divisions of a publication that
> overarch the content. Front matter in most English texts, for example, is
> demarked by roman numerals and contains title pages, tables of contents,
> dedications, forwards, etc.
>
>
>
> You don’t necessarily have to pick only one semantic, in other words, as
> this isn’t the role attribute where only one is recognized. All of the
> listed semantics are applicable. This is also because the semantics (and
> epub:type) were designed first for publishers wanting to use the semantics
> in internal workflows.
>
>
>
> They then took on a life of their own and have been used (and abused) in a
> variety of ways for different purposes in EPUB. Placing them on links in
> the landmarks is a useful hack, for example, but what does it mean that a
> link is the front matter and/or a forward? That the semantics describe what
> is at the end of the link is a creation that only exists for the landmarks,
> I believe.
>
>
>
> Structuring the list of landmarks probably does nothing but further
> complex an underutilized feature of EPUB. You’re starting to turn it back
> into a table of contents. You could put two semantics on a single item if
> it makes sense (e.g., a forward is also your first piece of front matter),
> but otherwise I’d keep the list flat. I’m kind of surprised the restriction
> to a flat list of entries, as we have for the page list, isn’t also defined
> for the landmarks.
>
>
>
> > why is the Structural Semantics Vocabulary non-normative in the
> Recommendation?
>
>
>
> The appendixes are normative unless marked otherwise and I don’t see a
> non-normative label on the vocabulary. Where are you seeing it is
> informative?
>
>
>
> Matt
>
>
>
> *From:* John Foliot <john@foliot.ca>
> *Sent:* July 29, 2021 12:45 PM
> *To:* W3C EPUB 3 Working Group <public-epub-wg@w3.org>; Avneesh Singh <
> avneesh.sg@gmail.com>; Ivan Herman <ivan@w3.org>
> *Subject:* Looking for some clarification
>
>
>
> Hi All,
>
>
>
> As I continue to digest the current EPUB 3.3 Rec, I'd like to ask some
> specific questions (if I may) regarding *Structural Semantics Vocabulary**.
>
>
> Specifically, I am looking to understand the
> relationship/similarities/differences between Document Partitions
> <https://www.w3.org/TR/epub-33/#partitions> and Document Sections and
> Components <https://www.w3.org/TR/epub-33/#sections>, as they appear (to
> me) to be very similar in function. (But, for example, would/could a
> Section or Component be a child of a Partition? Or are they hierarchically
> equal? )
>
>    - Looking specifically at usage in <nav epub:type="landmarks">, is
>    there a *minimum set* or collection of landmark-values expected in a
>    publication?
>
>
>    - if yes, what are they?
>       - if no, should there be? (why/why not?)
>
>
>    - Additionally, from an accessibility perspective, while the Rec is
>    currently silent on this specific scenario, based on the following supplied code
>    example <https://www.w3.org/TR/epub-33/#example-33> I am *presuming*
>    that the Partition value (actually, any epub:type's value) should also use
>    a "Human Readable" label (accessible name), as seen here with the epub:type
>    of *bodymatter*, where the label is *Start of Content*:
>
> <*nav* epub:type="landmarks">
>
>     <*h2*>Guide</*h2*>
>
>     <*ol*>
>
>         <*li*><*a* epub:type="toc" href="#toc">Table of Contents</*a*></
> *li*>
>
>         <*li*><*a* epub:type="loi" href="content.html#loi">List of
> Illustrations</*a*></*li*>
>
>         <*li*><*a* epub:type="bodymatter" href="content.html#bodymatter">Start
> of Content</*a*></*li*>
>
>     </*ol*>
>
> </*nav*>
>
>
>
> I ask this, because currently I am seeing (in sample books I am reviewing)
> that in many instances the epub:type value is being echoed as the
> human-readable label as well (i.e. *<a epub:type="Frontmatter"
> href="...">Frontmatter</a>*), which my gut is cringing at, as being less
> than useful for some users with different forms of cognitive disability.
> (It's a bit of a stretch to be sure, but WCAG SC 3.1.3 Unusual Words
> <https://www.w3.org/TR/WCAG21/#unusual-words> (Level AAA) states: *A
> mechanism is available for identifying specific definitions of words or
> phrases used in an unusual or restricted way, including idioms and jargon.
> - *and to *my* mind at least, *Frontmatter *is fairly "jargony
> <https://www.w3.org/TR/WCAG21/#dfn-jargon>" on the surface - it's clearly
> not a common term in regular public usage AFAIK. Ditto "backmatter".)
> (@Avneesh?)
>
>
>    - Returning to  *Document Partitions* vs. *Document Sections and
>    Components*, does one category have stronger or more important
>    semantics in practical usage? i.e. both *Frontmatter *and *Forward *feel
>    very similar (synonymous?) to each other conceptually - If I had to choose
>    just one, which would/should I choose? (and why?) Or, as I asked
>    previously, could I/would I seek to do something like this?
>
> <*nav* epub:type="landmarks">
>
>     <*h2*>Guide</*h2*>
>
>     <*ol*>
>
>         <*li*><*a* epub:type="Frontmatter" href="content.html#frontmatter"
> >Frontmatter</*a*> (* ya, yech)
>
>             <ol>
>
>                 <li><a epub:type="Forward"
> href="content.html#forward">Forward</a></li>
>
>                 <li><a epub:type="Preface"
> href="content.html#preface">Preface</a></li>
>
>             </ol>
>
>         </*li*>
>
>         <*li*><*a* epub:type="loi" href="content.html#loi">List of
> Illustrations</*a*></*li*>
>
>         <*li*><*a* epub:type="bodymatter" href="content.html#bodymatter">Start
> of Content</*a*></*li*>
>
>     </*ol*>
>
> </*nav*>
>
> (Or am I overthinking this?)
>
> Thanks in advance for any insights you can provide me.
>
>
>
> JF
>
>
>
> (* At the risk of asking too many questions, why is the Structural
> Semantics Vocabulary non-normative in the Recommendation? It appears to be
> furnishing specific definitions to multiple value terms. As a standards
> wonk, it strikes me that those definitions would probably want to be
> normative - or, again, am I missing something here? @Ivan - has there been
> any discussion of moving those definitions into the proposed W3C Registry
> <https://github.com/w3c/w3process/pull/335>?)
>
> --
>
> *John Foliot* | Senior Industry Specialist, Digital Accessibility
>
> "I made this so long because I did not have time to make it shorter." -
> Pascal "links go places, buttons do things"
>
>
>
>
> --
>
> *John Foliot* | Senior Industry Specialist, Digital Accessibility
>
> "I made this so long because I did not have time to make it shorter." -
> Pascal "links go places, buttons do things"
>


-- 
*John Foliot* | Senior Industry Specialist, Digital Accessibility

"I made this so long because I did not have time to make it shorter." -
Pascal "links go places, buttons do things"