- From: Richard Schwerdtfeger <schwer@us.ibm.com>
- Date: Tue, 31 Mar 2015 10:49:26 -0500
- To: Matt Garrish <matt.garrish@bell.net>, public-dpub-aria@w3.org
- Cc: "Michael Cooper" <cooper@w3.org>, "James Craig" <jcraig@apple.com>, Matthew King <mattking@us.ibm.com>, mgylling@idpf.org, "HTMLWG WG" <public-html@w3.org>, "W3C WAI Protocols & Formats" <public-pfwg@w3.org>, tsiegman@wiley.com
- Message-ID: <OFB0D49D4C.A0FF8E0E-ON86257E19.005687B9-86257E19.0056EC41@us.ibm.com>
Folks, I was wondering why I was not seeing comments. There is a public-dpub-aria list where comments should go. The task force did not send out for comments to the HTML working group. Please send comments there. It was resolved at the face to face meeting that we would not have hyphenated pseudo namespace roles for DPUB as there would be tremendous pushback by the publishing industry. This was conveyed to us by members of the dpub interest group. That said, the dpub-aria task force has been avoiding the use of hyphens should we require them in the future. James's point is well taken. Rich Rich Schwerdtfeger From: Matt Garrish <matt.garrish@bell.net> To: "James Craig" <jcraig@apple.com> Cc: Matthew King/Fishkill/IBM@IBMUS, "Michael Cooper" <cooper@w3.org>, <mgylling@idpf.org>, "HTMLWG WG" <public-html@w3.org>, "W3C WAI Protocols & Formats" <public-pfwg@w3.org>, <tsiegman@wiley.com> Date: 03/17/2015 08:38 AM Subject: Re: DPUB module comments > Might DPUB define this as an id? > <nav id="landmarks"> It'll be hit and miss whether an approach like that could work. Maybe for the landmarks since in EPUB it's a component of the navigation document, but there aren't that many niche cases. What I find problematic is that pinning semantics to IDs ultimately intrudes into the authoring sphere, and tries to layer meaning where it wasn't intended. Did the author want to identify a structure, or did they just happen to use an ID that matches a specification requirement they may not have been aware of? That's why we have the epub:type attribute. Publishers are typically also using their own identification systems for content (think CMS and content aggregation), so pushing simple ID naming conventions is going to prove problematic, as it forces the content creators to fall back on the kinds of models (epub:type) that we're trying to move away from. And it will lead to conflicts. A work as a whole might have a table of contents, but then every section within it might also have a table of contents at the start. Now you're forced to break your content up into separate documents to avoid naming conflicts, even if it's not what you want. But to try and make a long story shorter, it was discussed and agreed at the last call that the name "landmarks" is problematic, so the ball is back in Markus, Tzviya and my court to fix that role. At the very least, that name won't be in the final vocabulary list. And hopefully we'll have a definition that doesn't sound so much like a generic nav. Matt
Attachments
- image/gif attachment: graycol.gif
Received on Tuesday, 31 March 2015 15:49:59 UTC