- From: MURATA Makoto <eb2m-mrt@asahi-net.or.jp>
- Date: Tue, 27 Jun 2017 16:49:40 +0900
- To: Ivan Herman <ivan@w3.org>
- Cc: Bill McCoy <bmccoy@w3.org>, W3C Publishing Working Group <public-publ-wg@w3.org>, W3C Publishing Business Group <public-publishingbg@w3.org>
- Message-ID: <CALvn5EAci9c35-O644vV8NZPS=ASbE2JuUimD_4t5=0S7K=4Rg@mail.gmail.com>
Ivan, Are there any W3C members which cannot join the Publishing WG because of IPR concerns? If this is the case, can the charter be revised? Regards, Makoto 2017-06-27 16:18 GMT+09:00 Ivan Herman <ivan@w3.org>: > (-cc the DPUB IG. The discussion is really in the WG and BG now.) > > On 27 Jun 2017, at 00:05, MURATA Makoto <eb2m-mrt@asahi-net.or.jp> wrote: > > Bill, > > I am not even sure that "a multi-resource ordered collection of > related content (aka publication)" is a piece of the complete > solution. I doubt if it is a red herring. > > I do not believe that enough analysis has been made especially from the > OWP side, since browser vendors have not participated in the > Publishing WG. > > > Makoto, > > I am not sure what you mean here; the Publishing WG has just started… > > Additionally to what Bill said: Some of the browser vendor representatives > have actually taken part of the DPUB IG discussions, too. Those discussions > (over 100 open issues on Github at some points in time!) have significantly > shaped the work of the DPUB IG and, as a consequence, the two input > documents to this WG, namely the PWP Use cases as well as the PWP document > itself. In other words, I believe you are a bit unfair to the work of the > DPUB IG. > > As Bill alluded to, some of the browser vendors wait for a more specific, > more precisely scoped set of features. The goal of the WG is to provide > those via a FPWD based on what we have worked on both in the DPUB IG as > well as in the IDPF EPUB 3.1 WG. Let us concentrate on that now, and > hopefully that will bring in other parties for a joint discussion. > > Ivan > > > > Regards, > Makoto > > 2017-06-27 6:48 GMT+09:00 Bill McCoy <whmccoy@gmail.com>: > >> Makoto, maybe you misunderstood the reasoning behind my proposal. >> >> I completely agree that " 'a multi-resource ordered >> collection of related content (aka publication)' will not unify the OWP >> and EPUB worlds". >> >> My proposal is based on the observation that in the decomposition of >> specs contemplated in our charter the Web Publications (WP) specification >> should not have the burden to fully unify the OWP and EPUB worlds: this is >> the job of everything that our new WG has to do, and that much of the >> unification will necessarily be in the PWP/EPUB4 realm. If we have to solve >> everything before we do anything we will not get started quickly, if ever, >> and then we won't get anywhere. So I propose that we do first cut at WP in >> an agile manner even though we realize in the end it will be only one piece >> of the complete solution. That will get us started and help keep things >> clean architecturally. >> >> And plenty of analysis has already been done both on IDPF side (work that >> started during but did not end up part of EPUB 3.1) and W3C side (DPUB IG >> deliverables). So I fear "analysis paralysis" if we stay in that mode. >> >> --Bill >> >> >> >> On Mon, Jun 26, 2017 at 2:39 PM, MURATA Makoto <eb2m-mrt@asahi-net.or.jp> >> wrote: >> >>> -1 >>> >>> Although I think that the charter has to be revised for inviting >>> browser vendors, I do not think that the "a multi-resource ordered >>> collection of related content (aka publication)" unifies the OWP >>> and EPUB worlds. I rather doubt if it is a re-engineering for the >>> purpose of re-engineering. We should rather begin with a thorough >>> analysis of the gaps between the OWP and EPUB worlds, >>> What does the Microsoft team for EPUB say about the gap? >>> >>> Regards, >>> Makoto >>> >>> 2017-06-27 0:39 GMT+09:00 Bill McCoy <bmccoy@w3.org>: >>> >>>> I thought the F2F was very successful but it seemed unclear coming out >>>> of it whether we are in consensus on the ideal scope of Web Publications >>>> (WP). >>>> >>>> >>>> >>>> Ivan said several times in the F2F that "this is the Web" but I don't >>>> know that it fully sunk in. So I would like to make a modest proposal for a >>>> way to help us move forward in a focused manner. >>>> >>>> >>>> >>>> I believe that the core gap in OWP that WP needs to fill is the lack of >>>> any definition of a multi-resource ordered collection of related content >>>> (aka publication). As such, I am not sure there is any other strong >>>> requirement for a Web Publication spec. The document outline created at the >>>> end of F2F to me seems to presume a much "thicker" spec particularly >>>> because much of the 2 days of discussion was about use cases for everything >>>> the WG needs to handle. >>>> >>>> >>>> >>>> I propose that a guiding principle be that for WP nothing is needed >>>> unless it is explicitly required for the use cases for online Web >>>> publications *BUT *not required for the use cases for Web pages and >>>> Web apps. If something is not about online distribution through the Web - >>>> content hosted at URL(s) - it should be in PWP/EPUB4 spec(s) not WP spec >>>> (“P” in PWP stands for "portable" not "packaged") If something is >>>> applicable to Web pages and Web apps as well as Web publication it should >>>> be a general Web Platform capability. At least that should be our starting >>>> presumption in crafting the initial WP spec draft. >>>> >>>> >>>> >>>> Thus for WP I am not sure we need anything except a means to define the >>>> collection of content (the publication) and a way to hang metadata on that >>>> collection, plus probably something about identification of publications. >>>> So, for agile development in MVP (minimum viable product) manner, I think >>>> we should affirmatively state that this is the assumption and draft >>>> accordingly. I.e. have a thin starting outline for WP spec, not a thick one. >>>> >>>> >>>> >>>> So by way of example there should be no going-in expectation of a need >>>> for a security section in the WP spec, as *WP is by definition “on the >>>> Web”* so normal Web security model applies. There should be no >>>> going-in expectation of a need to say anything about scripting. Etc. (we >>>> can be in parallel outlining PWP and move things like security and >>>> scripting there). I hate to say it, but there should not be a need to say >>>> anything about accessibility other than as it applies to the new things >>>> being specifically defined in the WP spec. >>>> >>>> >>>> >>>> Maybe we’ll find that we need to relax this… for example something that >>>> we need for publications, both on the Web and distributed via other means, >>>> that while theoretically useful for Web apps and simple Web pages is not in >>>> the cards to get done by Web Platform WG in our timetable. Maybe we’ll >>>> find that some PWP things have implications for WP-level mechanisms. >>>> >>>> >>>> >>>> But these things to me should be well-considered exceptions to our >>>> general expectations. We shouldn’t start our drafting with an presumption >>>> that we are going to be putting things in WP that are logically overall Web >>>> Platform mechanisms or putting stuff in WP even though not directly >>>> relevant for “on the Web” scenarios because we want to make sure it flows >>>> “down” to PWP distribution means. >>>> >>>> >>>> >>>> To me the only significant issue we need to wrestle with now in >>>> crafting a WP spec is whether the means of defining a collection of content >>>> is within HTML, as the privileged hypertext format of the Web, and/or an >>>> external data structure that is independent of content element format, >>>> and/or something implicit (such path elements of URLs) . If we agree on a >>>> minimal approach to WP I would hope that the WG can quickly move on to >>>> resolving this key issue so we can have a straw-man draft spec ASAP. >>>> >>>> >>>> If the WP spec thus becomes almost trivial – that would be something to >>>> celebrate! Not because the other things aren’t very important to the >>>> overall job of the Publishing WG – they are! But because a clean, modular >>>> architecture that doesn’t unnecessarily conflate things that don’t belong >>>> together will both help us get a faster start now, and serve us better in >>>> the long run. >>>> >>>> >>>> >>>> --Bill (not writing here with Team or Readium hat on, just as a WG >>>> participant) >>>> >>> >>> >>> >>> -- >>> >>> Praying for the victims of the Japan Tohoku earthquake >>> >>> Makoto >>> >> >> > > > -- > > Praying for the victims of the Japan Tohoku earthquake > > Makoto > > > > ---- > Ivan Herman, W3C > Publishing@W3C Technical Lead > Home: http://www.w3.org/People/Ivan/ > mobile: +31-641044153 <+31%206%2041044153> > ORCID ID: http://orcid.org/0000-0003-0782-2704 > > -- Praying for the victims of the Japan Tohoku earthquake Makoto
Received on Tuesday, 27 June 2017 07:50:15 UTC