- From: Bernhard Heinser <bernhard.heinser@access-for-all.ch>
- Date: Tue, 9 May 2017 15:01:11 +0200
- To: public-publishingbg@w3.org
- Message-ID: <69e7a389-65ff-7b22-08f5-8064efceabf5@access-for-all.ch>
+1 Am 09.05.2017 um 12:16 schrieb Wolfgang Schindler: > Hi all, > > in the EPUB ecosphere the host language HTML was enriched with > epub:type attributes to carry the structural semantics needed in > diverse fields (education, indexes, dictionaries, etc..). Whether we > express that information as @epub:type or as @role is just a syntactic > detail as long as the complete set of values for @epub:type from the > IDPF specs will be available as well-defined values for @role that > should be supported by any conforming RS. > > I think we should be very careful that we don't deprecate or supersede > @epub:type too quickly, before the adequate "port" of its > functionality to @role has been finished. I personally think we should > do our best not to lose years of development of a specialized > descriptive vocabulary at IDPF in a quick move to another model. As > Matt pointed out: "We also still lack the vocabulary to make it > feasible to bring many of the satellite specs forward with only role, > and if we supersede epub:type it has to be ignored by reading > systems." I fully agree with this position.. > > Wolfgang > > > 2017-05-08 21:41 GMT+02:00 Juli Calderazi <jcalderazi@gmail.com > <mailto:jcalderazi@gmail.com>>: > > Hello all. > As regards to: >> We could supersede epub:type, which keeps it for compatibility >> with older versions without generating any warnings. > I totally agree on this. To supersede. > > Julian M. Calderazi > Team Leader @ DigitalBe.com <http://digitalbe.com> > +54 9 11 6762 7351 <tel:+54%209%2011%206762-7351> > Buenos Aires, ARG > >> On May 8, 2017, at 14:40, Matt Garrish <matt.garrish@gmail.com >> <mailto:matt.garrish@gmail.com>> wrote: >> >> This is what I'm waiting to hear more about. Deprecation means >> warnings per the specification, so part of this may be my own >> pedantic reading of things. We could supersede epub:type, which >> keeps it for compatibility with older versions without generating >> any warnings. >> No one went for that option, though, as it means duplication of >> role+epub:type everywhere that epub:type has significance for >> 3.0. We also still lack the vocabulary to make it feasible to >> bring many of the satellite specs forward with only role, and if >> we supersede epub:type it has to be ignored by reading systems. >> Worrisome doesn't mean impossible, but if such a change were to >> be made it should be done asap before 3.1 takes legs without role >> for key content. >> Matt >> *From:*Bill Kasdorf [mailto:bkasdorf@apexcovantage.com >> <mailto:bkasdorf@apexcovantage.com>] >> *Sent:*May 8, 2017 12:33 PM >> *To:*Matt Garrish <matt.garrish@gmail.com >> <mailto:matt.garrish@gmail.com>>; 'Paul Belfanti' >> <Paul.Belfanti@ascendlearning.com >> <mailto:Paul.Belfanti@ascendlearning.com>>; 'Juli Calderazi' >> <jcalderazi@gmail.com <mailto:jcalderazi@gmail.com>> >> *Cc:*'Johnson, Rick' <Rick.Johnson@ingramcontent.com >> <mailto:Rick.Johnson@ingramcontent.com>>; >> public-publishingbg@w3.org <mailto:public-publishingbg@w3.org> >> *Subject:*RE: EPUB for Education (EDUPUB) proposal >> I think this is a legacy-vs.-going-forward issue. Deprecating >> epub:type in favor of role is the right thing to do when creating >> new content. But there is a ton of legacy, published, distributed >> content out there using epub:type so it has to continue to be >> allowed. The new spec should encourage transitioning content from >> epub:type to role, and imo should also recommend that RS support >> both (is that an issue? I’m not an RS person). It should also be >> pointed out that role is preferred (required?) for accessibility. >> Bill Kasdorf >> VP and Principal Consultant |*Apex CoVantage* >> p: >> >> 734-904-6252 <tel:%28734%29%20904-6252> m:734-904-6252 >> <tel:%28734%29%20904-6252> >> >> ISNI:http://isni.org/isni/0000000116490786 >> <http://isni.org/isni/0000000116490786> >> >> ORCiD:https://orcid..org/0000-0001-7002-4786 >> <https://orcid.org/0000-0001-7002-4786?lang=en> >> *From:*Matt Garrish [mailto:matt.garrish@gmail.com] >> *Sent:*Monday, May 08, 2017 10:46 AM >> *To:*'Paul Belfanti'; 'Juli Calderazi' >> *Cc:*'Johnson, Rick';public-publishingbg@w3.org >> <mailto:public-publishingbg@w3.org> >> *Subject:*RE: EPUB for Education (EDUPUB) proposal >> I think the comment under section 8 about investigating epub:type >> alternatives is supposed to be with this vocabulary. >> The metadata and vocabulary under section 8 is all schema.org >> <http://schema.org> and implemented through rdfa/microdata/json, >> so further integration with W3C doesn't seem applicable. >> (Dropping the LRMI vocabulary is noted in the appendix as a to >> do, so there's hopefully even less the CG would have to do.) >> Deprecating epub:type in a 3.1.x release after agreeing it was >> too big a change for a 3.x release strikes me as worrisome, but >> I'll wait to see how that actually plays out.. :) >> Matt >> *From:*Paul Belfanti [mailto:Paul.Belfanti@ascendlearning.com >> <mailto:Paul.Belfanti@ascendlearning.com>] >> *Sent:*May 8, 2017 10:09 AM >> *To:*Juli Calderazi <jcalderazi@gmail.com >> <mailto:jcalderazi@gmail.com>> >> *Cc:*Johnson, Rick <Rick.Johnson@ingramcontent.com >> <mailto:Rick.Johnson@ingramcontent.com>>;public-publishingbg@w3.org >> <mailto:public-publishingbg@w3.org> >> *Subject:*Re: EPUB for Education (EDUPUB) proposal >> That’s correct, Juli. >> Paul >> — >> Paul Belfanti >> Vice President, Production, Manufacturing & Content Architecture >> (w) 978.639.3536 <tel:%28978%29%20639-3536> >> (m) 201.783.4884 <tel:%28201%29%20783-4884> >> *From:*Juli Calderazi <jcalderazi@gmail.com >> <mailto:jcalderazi@gmail.com>> >> *Date:*Monday, May 8, 2017 at 10:04 AM >> *To:*Paul Belfanti <Paul.Belfanti@ascendlearning.com >> <mailto:Paul.Belfanti@ascendlearning.com>> >> *Cc:*Rick Johnson <Rick.Johnson@ingramcontent.com >> <mailto:Rick.Johnson@ingramcontent.com>>, >> "public-publishingbg@w3.org <mailto:public-publishingbg@w3.org>" >> <public-publishingbg@w3.org <mailto:public-publishingbg@w3.org>> >> *Subject:*Re: EPUB for Education (EDUPUB) proposal >> Paul, you are making reference to the structural vocabulary? >> Julian M. Calderazi >> Team Leader @ DigitalBe.com <http://digitalbe.com/> >> +54 9 11 6762 7351 <tel:+54%209%2011%206762-7351> >> Buenos Aires, ARG >>> On May 8, 2017, at 10:47, Paul Belfanti >>> <Paul.Belfanti@ascendlearning.com >>> <mailto:Paul.Belfanti@ascendlearning.com>> wrote: >>> Rick, >>> This plan seems practical. The only thing that’s unclear to me >>> is what happens to the expanded semantics associated with >>> education content. Will that be fully deprecated, and if so, how >>> do we account for the structural needs of the edu segment? >>> Thanks, >>> Paul >>> — >>> Paul Belfanti >>> Vice President, Production, Manufacturing & Content Architecture >>> (w) 978.639.3536 <tel:%28978%29%20639-3536> >>> (m) 201.783.4884 <tel:%28201%29%20783-4884> >>> *From:*Rick Johnson <Rick.Johnson@ingramcontent.com >>> <mailto:Rick.Johnson@ingramcontent.com>> >>> *Date:*Saturday, May 6, 2017 at 12:48 PM >>> *To:*"public-publishingbg@w3.org >>> <mailto:public-publishingbg@w3.org>" <public-publishingbg@w3.org >>> <mailto:public-publishingbg@w3..org>> >>> *Subject:*EPUB for Education (EDUPUB) proposal >>> *Resent-From:*<public-publishingbg@w3.org >>> <mailto:public-publishingbg@w3.org>> >>> *Resent-Date:*Saturday, May 6, 2017 at 12:49 PM >>> All, >>> For discussion on Tuesday’s business group call: >>> After discussions among the steering committee, and with the >>> community group chairs, and with IMS Global board members and >>> staff, I would like to make this proposal for a path forward for >>> the EPUB for Education (EDUPUB) specification: >>> EDUPUB/EPUB for Education Proposal >>> (referencing the current draft at >>> http://www.idpf.org/epub/profiles/edu/spec/ >>> <http://www.idpf.org/epub/profiles/edu/spec/> ) >>> *Consolidate work around the EPUB 3.1 specification:* >>> All accessibility work, the ‘Education Document Models’ (section >>> 3), Annotations (section 9), Navigation (section 7), and the >>> inclusion of scriptable components (section 5) or distributable >>> objects (section 10) are the purview of, and stated to align >>> with the W3C work on EPUB and future iterations of EPUB. In >>> short, we tell people to use EPUB 3.1, and future versions for >>> these items. The work done for EDUPUB is deprecated in favor of >>> EPUB 3.1 and future versions. This includes the ‘Content >>> Structure’ details in section 4 (in essence, the content >>> structure details and associated metadata defined in >>> Accessibility 1.0 are all that will be made normative). >>> The ‘Publication Metadata’ (section 8 and the related >>> vocabulary)) have value to be made normative for educational >>> use, and should be given to the CG to finalize as a set of >>> specifications for educational use of EPUB 3.1. Attention >>> should be given to harmonizing this work with other W3C >>> investigations, such as is illustrated in the comment at >>> https://github.com/w3c/html/issues/846#issuecomment-290399200 >>> <https://github.com/w3c/html/issues/846#issuecomment-290399200>. >>> Where it makes sense, these can be rolled into a 3.1.x release. >>> Special care should be drawn to the deprecation of epub type and >>> the move to role in a 3.1.x release. >>> Dealing with (section 6) outcome results flowing back to a grade >>> book, and integration with educational systems needing >>> interoperability (such as LTI) are not the purview of a >>> horizontally focused organization (like the W3C), and should be >>> given over to a vertically focused organization (like IMS >>> Global) to standardize any needed best practices and >>> certification procedures. We should allow them to have the >>> freedom to use the EDUPUB name for that set of specifications, >>> if they so desire. >>> -Rick >>> >>> >>> CONFIDENTIALITY NOTICE: This e-mail message including >>> attachments, if any, is intended for the person or entity to >>> which it is addressed and may contain confidential, privileged, >>> and/or proprietary material. Any unauthorized review, use, >>> disclosure or distribution is prohibited. If you are not the >>> intended recipient, please contact the sender by reply e-mail >>> and destroy all copies of the original message. >> > > -- Bernhard Heinser Mobile: +41 (0)79 703 37 71 Swiss Foundation Access for All / CEO (www.access-for-all.ch) bernhard.heinser@access-for-all.ch
Received on Tuesday, 9 May 2017 13:02:06 UTC