Planet MathML

The Planet MathML aggregates posts from various blogs that concern MathML. Although it is hosted by W3C, the content of the individual entries represent only the opinion of their respective authors and does not reflect the position of W3C.

Latest articles

Re: [wbs] response to 'Call for Review: Publishing Working Group Charter'

Source: public-digipub-ig@w3.org Mail Archives • Ivan Herman (ivan@w3.org) • April 27, 2017 • Permalink

Hi Florian,

While my previous reply was looking at the administrative aspect of handling the changes, this one is on the content.  I did not reply to this earlier because I wanted to broaden the discussion on your proposal with the W3C Team as well as the PUB BG.

We observe that this proposed change to Section 3 is a fairly significant one that will influence the group's dynamics. We are pleased to see that there are other voices that chime in and evolve the proposals; as a consequence I propose to leave this specific issue open during the official review period and let relevant discussions take their course for now. I hope this is fine with you.

Sincerely

Ivan


> On 26 Apr 2017, at 04:26, Florian Rivoal <florian@rivoal.net> wrote:
> 
> Hi,
> 
> Yes, in broad lines, this change would remove my objection.
> 
> Now, in details, I would write it a little differently.
> 
> * Your phrasing suggest that we need to agree on all deliverables first, then start. Maybe this will happen, but more likely in my opinion, we may reach consensus quickly on some deliverables (e.g. DPUB-ARIA-2) and take a bit more time to figure out the concrete proposals for (P)WP and EPUB 4. Not having full agreement on everything should not block us from starting on the things where we do have agreement. So here's a suggestion:
> 
> * As we cannot predict how long it will take to reach consensus on each deliverable, having milestones does not seem useful at this point, and may even be counter productive as it seems to suggest that publication should be date driven rather than consensus driven.
> 
> Concretely, I would:
> 
> 1) tweak the text you proposed a little:
> 
>> "The requirements, concepts, and suggested deliverables listed here have been derived from the preliminary considerations of the Digital Publishing Interest Group (see, for example, the PWP-UCR document) as well as the experiences from the EPUB 3.1 Working Group of the IDPF, especially its work on "Browser-friendly Manifestations". One of the first tasks of the Working Group will be to make a thorough review of these proposals and how they fit with specifications from other Working Groups. As concrete proposals are made, reach sufficient maturity and achieve consensus (See <a href="https://www.w3.org/Guide/standards-track/#criteria">Readiness Criteria</a> for guidelines), individual deliverables will be added. The detailed list, milestones, and updated publication schedules will be maintained on the <a href="@@@">group publication status page.</a> "
> 
> 
> 2) Rename the "Recommendation-track Deliverables" to "Suggested Recommendation-track Deliverables", and delete the introductory sentence ("The working group will deliver .... ), since it is now covered by the paragraph we just discussed.
> 
> 3) In section 3.3, keep the introduction sentence and the face-to-face meetings, but remove the document milestones.
> 
> 
> Although the wording is a little different, I believe this is in agreement with the discussion we had during the AC meeting. Would this work for you?
> 
> —Florian
> 
> 
>> On Apr 25, 2017, at 16:06, Johnson, Rick <Rick.Johnson@ingramcontent.com> wrote:
>> 
>> Florian,
>> 
>> After our conversation at lunch, and assuming acceptance of the proposed changes already communicated around the objections raised by Daniel, does the below resolve your remaining objections?
>> 
>> -Rick
>> 
>> 
>> 
>> Replace in section 3. Deliverables, the first line:
>>    “More detailed milestones and updated publication schedules are available on the group publication status page”
>> 
>> with the following:
>> 
>> "The requirements, concepts, deliverables, and milestones listed here have been derived from the preliminary considerations of the Digital Publishing Interest Group (see, for example, the PWP-UCR document) as well as the experiences from the EPUB 3.1 Working Group of the IDPF, especially its work on "Browser-friendly Manifestations". One of the first tasks of the Working Group will be to make a thorough review, achieve consensus on, and document the final list, milestones, and the content of the deliverables of the group.  The more detailed list, milestones, and updated publication schedules are available on the <a href="@@@">group publication status page.</a> "
>> 
>> 
>> 
>> On 4/18/17, 1:30 PM, "Florian Rivoal via WBS Mailer" <sysbot+wbs@w3.org> wrote:
>> 
>>   The following answers have been successfully submitted to 'Call for Review:
>>   Publishing Working Group Charter' (Advisory Committee) for Vivliostyle Inc.
>>   by Florian Rivoal.
>> 
>> 
>>   The reviewer's organization suggests changes to this Charter, and only
>>   supports the proposal if the changes are adopted [Formal Objection].
>> 
>>   Additional comments about the proposal:
>>      Vivliostyle enthusiastically supports the creation of the Publishing
>>   Working Group, its high level goals and scope, and the general format
>>   proposed in the charter.
>> 
>>   However, we think there is an important flaw in the charter that must be
>>   addressed first.
>> 
>>   Web Publications outlines a vision of convergence between digital
>>   publications and the web. We absolutely support this vision, and hope to
>>   contribute to its realization, both by participating in the WG and by
>>   integrating these technologies in our products. Convergence of digital
>>   publications and of the web is central to Vivliostyle's mission as a
>>   company.
>> 
>>   However, to our reading, the existing Web Publications documents are a
>>   manifesto and declaration of intent, not a concrete proposal to address the
>>   problem.
>> 
>>   As such, we believe that (P)WP should be in scope for this working group,
>>   and that concrete proposals to achieve this goal should be made, and when
>>   consensual should be taken up as deliverables of this working group.
>> 
>>   We are however opposed to listing WP and PWP themselves as a REC track
>>   deliverable with dated commitments.
>> 
>>   If "Web Publications" and "Packaged Web Publications" are meant to stay as
>>   general documents outlining the vision independently of any concrete
>>   implementable and testable incarnation, we think it would be much more
>>   appropriate to publish them as WG Notes.
>> 
>>   If, as their proposed inclusion on the REC track suggests, they are meant
>>   to be concrete technological proposals, we think the inclusion on the REC
>>   track is premature, as we do not believe there is consensus on, or even a
>>   general understanding of, what the concrete realization would be.
>> 
>>   Our concrete proposal is to:
>> 
>>   - List WP and PWP as deliverables as Working Group Notes and continue to
>>   refine them as vision and requirements documents
>> 
>>   - Give the possibility to the group to take on new deliverables that help
>>   achieve that vision when they are consensual, possibly by including
>>   something along these lines in the charter (inspired by the CSSWG
>>   charter):
>> 
>>> The WG may create new modules within its scope to fulfill or support the
>>> vision outlined in WP and PWP. If no participant in the group believes a
>>> proposed module is out of scope, and the group has consensus to add it,
>>> the group may add a new module. If the participants who object sustain
>>> their objection after discussion, a re-charter to clarify the scope may
>>   be
>>> needed.
>> 
>>   ~~~
>> 
>>   Independently from this objection, we also make the following suggestion
>>   (but do not oppose the creation of the WG on these grounds even if it was
>>   rejected):
>> 
>>   For the sake of maintainability and timely progress along the REC track, it
>>   is sometimes desirable to split a large specification into smaller modules
>>   (or to do the reverse operation). We do not think it is necessary at this
>>   point to decide whether to split any particular document into smaller
>>   modules, but it would be good to keep it as a possibility. We therefore
>>   suggest the addition of the following sentence to the deliverable section.
>> 
>>> Also, to facilitate timely progress on the REC track and for
>>> the sake of maintainability, based on consensus in the Working
>>> Group, it may split or merge its deliverables.
>> 
>> 
>> 
>>   The reviewer's organization intends to participate in these groups:
>>      - Publishing Working Group
>> 
>>   The reviewer's organization:
>>      - intends to review drafts as they are published and send comments.
>>      - intends to develop experimental implementations and send experience
>>   reports.
>>      - intends to develop products based on this work.
>>      - intends to apply this technology in our operations.
>> 
>> 
>>   Comments about the deliverables:
>>      Vivliostyle develops Vivliostyle Viewer and Vivliostyle Formatter,
>>   respecively an interactive UA and a pdf-generating UA, with support for
>>   pagination and advanced typographic features based on CSS (and (X)HTML,
>>   SVG, MathML...).
>> 
>>   Vivliostyle's product provide an answer to Pagination
>>     https://www.w3.org/TR/2017/WD-pwp-ucr-20170309/#pagination
>>   and also intends facilitate Off-lining and Archiving
>>     https://www.w3.org/TR/2017/WD-pwp-ucr-20170309/#onloffl
>>     https://www.w3.org/TR/2017/WD-pwp-ucr-20170309/#archiving
>> 
>>   We currently support ordinary web content as well as EPUB3 as input
>>   formats, and intend to support EPUB4 and other (P)WP formats as they
>>   appear.
>> 
>> 
>>   Answers to this questionnaire can be set and changed at
>>   https://www.w3.org/2002/09/wbs/33280/publwg/ until 2017-05-14.
>> 
>>    Regards,
>> 
>>    The Automatic WBS Mailer
>> 
>> 
>> 
>> 
> 
> 


----
Ivan Herman, W3C
Publishing@W3C Technical Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704





Re: [wbs] response to 'Call for Review: Publishing Working Group Charter'

Source: public-digipub-ig@w3.org Mail Archives • Leonard Rosenthol (lrosenth@adobe.com) • April 27, 2017 • Permalink

Much better – thanks!   In fact, I think it says exactly what we all expect to be doing but now is well spelled out.

Thanks again for helping us get this approved.

Leonard

On 4/27/17, 3:07 AM, "Florian Rivoal" <florian@rivoal.net> wrote:

    Hi Leonard,
    
    "a thorough review of these proposals" is probably the wrong phrasing. I agree that re-reading and re-tweaking the existing (P)WP documents would mostly be a waste of time. 
    
    What I mean is that concrete proposals with normative prose need to be made, evaluated for their own merits, evaluated on how they fit into the rest of the platform, matured somewhat... in other words be incubated, **before** we can decide to put them on TR.
    
    Some members insist that this incubation must be done in Community Groups prior to the creation of the WG. I am (infamously?) not of that opinion, and think incubation is perfectly doable within a WG, so long as the WG takes this incubation seriously and has the necessary community (which we do have). So, I think we should charter the WG, do so without deliverables (because we have not yet incubated anything), then members should make proposals, those that seem half way reasonable should become EDs, and only once these EDs are sufficiently refined that we can get consensus that they not only address the right problem, but also address it the right way, then we can decide to put them on TR.
    
    So yes, we should start actual work, but no, we should not put it on TR just yet, nor agree to do so before seeing and thinking hard about the actual proposals.
    
    So based on this, I propose this new re-wording (keeping point 2 and 3 of my last mail unchanged):
    
    > "The requirements, concepts, and suggested deliverables listed here have been derived from the preliminary considerations of the Digital Publishing Interest Group (see, for example, the PWP-UCR document) as well as the experiences from the EPUB 3.1 Working Group of the IDPF, especially its work on "Browser-friendly Manifestations". Informed (but not constrained) by these, concrete proposals now need to be drafted, incubated, and evaluated on their own merits and on how they fit in the rest of the platform. As they reach sufficient maturity and achieve consensus (See <a href="https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FGuide%2Fstandards-track%2F%23criteria&data=02%7C01%7C%7C66a563f2d56f4b24e0c708d48d552c4b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636288844332835514&sdata=JT9KQj2cjuRgooZIYFkhfZW51CytxChrOaRsieY1BiE%3D&reserved=0">Readiness Criteria</a> for guidelines), individual deliverables will be added. The detailed list, milestones, and updated publication schedules will be maintained on the <a href="@@@">group publication status page.</a> "
    
    
    Would that work better for you?
    
    —Florian
    
    
    > On Apr 26, 2017, at 11:31, Leonard Rosenthol <lrosenth@adobe.com> wrote:
    > 
    > I, for one, have issues with the revised wording.  
    > 
    > I don’t believe that “a thorough review of these proposals…” is a mandatory requirement for us to move forward on the deliverables as we see them – in fact, I might argue that they would be an unwelcome distraction.   Mandating a process is not helpful.   The WG should focus on the deliverables – as the current Charter defines – and the process will work itself out.  
    > 
    > Leonard
    > 
    > On 4/25/17, 7:26 PM, "Florian Rivoal" <florian@rivoal.net> wrote:
    > 
    >    Hi,
    > 
    >    Yes, in broad lines, this change would remove my objection.
    > 
    >    Now, in details, I would write it a little differently.
    > 
    >    * Your phrasing suggest that we need to agree on all deliverables first, then start. Maybe this will happen, but more likely in my opinion, we may reach consensus quickly on some deliverables (e.g. DPUB-ARIA-2) and take a bit more time to figure out the concrete proposals for (P)WP and EPUB 4. Not having full agreement on everything should not block us from starting on the things where we do have agreement. So here's a suggestion:
    > 
    >    * As we cannot predict how long it will take to reach consensus on each deliverable, having milestones does not seem useful at this point, and may even be counter productive as it seems to suggest that publication should be date driven rather than consensus driven.
    > 
    >    Concretely, I would:
    > 
    >    1) tweak the text you proposed a little:
    > 
    >> "The requirements, concepts, and suggested deliverables listed here have been derived from the preliminary considerations of the Digital Publishing Interest Group (see, for example, the PWP-UCR document) as well as the experiences from the EPUB 3.1 Working Group of the IDPF, especially its work on "Browser-friendly Manifestations". One of the first tasks of the Working Group will be to make a thorough review of these proposals and how they fit with specifications from other Working Groups. As concrete proposals are made, reach sufficient maturity and achieve consensus (See <a href="https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FGuide%2Fstandards-track%2F%23criteria&data=02%7C01%7C%7C1153d04e26d84fb24f5a08d48c4bd065%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636287704672245455&sdata=dCNopqCO62SiZNieCwzggQFEJp5d6kOFRSW%2F3PBV3%2FQ%3D&reserved=0">Readiness Criteria</a> for guidelines), individual deliverables will be added. The detailed list, milestones, and updated publication schedules will be maintained on the <a href="@@@">group publication status page.</a> "
    > 
    > 
    >    2) Rename the "Recommendation-track Deliverables" to "Suggested Recommendation-track Deliverables", and delete the introductory sentence ("The working group will deliver .... ), since it is now covered by the paragraph we just discussed.
    > 
    >    3) In section 3.3, keep the introduction sentence and the face-to-face meetings, but remove the document milestones.
    > 
    > 
    >    Although the wording is a little different, I believe this is in agreement with the discussion we had during the AC meeting. Would this work for you?
    > 
    >    —Florian
    > 
    > 
    >> On Apr 25, 2017, at 16:06, Johnson, Rick <Rick.Johnson@ingramcontent.com> wrote:
    >> 
    >> Florian,
    >> 
    >> After our conversation at lunch, and assuming acceptance of the proposed changes already communicated around the objections raised by Daniel, does the below resolve your remaining objections?
    >> 
    >> -Rick
    >> 
    >> 
    >> 
    >> Replace in section 3. Deliverables, the first line:
    >>    “More detailed milestones and updated publication schedules are available on the group publication status page”
    >> 
    >> with the following:
    >> 
    >> "The requirements, concepts, deliverables, and milestones listed here have been derived from the preliminary considerations of the Digital Publishing Interest Group (see, for example, the PWP-UCR document) as well as the experiences from the EPUB 3.1 Working Group of the IDPF, especially its work on "Browser-friendly Manifestations". One of the first tasks of the Working Group will be to make a thorough review, achieve consensus on, and document the final list, milestones, and the content of the deliverables of the group.  The more detailed list, milestones, and updated publication schedules are available on the <a href="@@@">group publication status page.</a> "
    >> 
    >> 
    >> 
    >> On 4/18/17, 1:30 PM, "Florian Rivoal via WBS Mailer" <sysbot+wbs@w3.org> wrote:
    >> 
    >>   The following answers have been successfully submitted to 'Call for Review:
    >>   Publishing Working Group Charter' (Advisory Committee) for Vivliostyle Inc.
    >>   by Florian Rivoal.
    >> 
    >> 
    >>   The reviewer's organization suggests changes to this Charter, and only
    >>   supports the proposal if the changes are adopted [Formal Objection].
    >> 
    >>   Additional comments about the proposal:
    >>      Vivliostyle enthusiastically supports the creation of the Publishing
    >>   Working Group, its high level goals and scope, and the general format
    >>   proposed in the charter.
    >> 
    >>   However, we think there is an important flaw in the charter that must be
    >>   addressed first.
    >> 
    >>   Web Publications outlines a vision of convergence between digital
    >>   publications and the web. We absolutely support this vision, and hope to
    >>   contribute to its realization, both by participating in the WG and by
    >>   integrating these technologies in our products. Convergence of digital
    >>   publications and of the web is central to Vivliostyle's mission as a
    >>   company.
    >> 
    >>   However, to our reading, the existing Web Publications documents are a
    >>   manifesto and declaration of intent, not a concrete proposal to address the
    >>   problem.
    >> 
    >>   As such, we believe that (P)WP should be in scope for this working group,
    >>   and that concrete proposals to achieve this goal should be made, and when
    >>   consensual should be taken up as deliverables of this working group.
    >> 
    >>   We are however opposed to listing WP and PWP themselves as a REC track
    >>   deliverable with dated commitments.
    >> 
    >>   If "Web Publications" and "Packaged Web Publications" are meant to stay as
    >>   general documents outlining the vision independently of any concrete
    >>   implementable and testable incarnation, we think it would be much more
    >>   appropriate to publish them as WG Notes.
    >> 
    >>   If, as their proposed inclusion on the REC track suggests, they are meant
    >>   to be concrete technological proposals, we think the inclusion on the REC
    >>   track is premature, as we do not believe there is consensus on, or even a
    >>   general understanding of, what the concrete realization would be.
    >> 
    >>   Our concrete proposal is to:
    >> 
    >>   - List WP and PWP as deliverables as Working Group Notes and continue to
    >>   refine them as vision and requirements documents
    >> 
    >>   - Give the possibility to the group to take on new deliverables that help
    >>   achieve that vision when they are consensual, possibly by including
    >>   something along these lines in the charter (inspired by the CSSWG
    >>   charter):
    >> 
    >>> The WG may create new modules within its scope to fulfill or support the
    >>> vision outlined in WP and PWP. If no participant in the group believes a
    >>> proposed module is out of scope, and the group has consensus to add it,
    >>> the group may add a new module. If the participants who object sustain 
    >>> their objection after discussion, a re-charter to clarify the scope may
    >>   be
    >>> needed.
    >> 
    >>   ~~~
    >> 
    >>   Independently from this objection, we also make the following suggestion
    >>   (but do not oppose the creation of the WG on these grounds even if it was
    >>   rejected):
    >> 
    >>   For the sake of maintainability and timely progress along the REC track, it
    >>   is sometimes desirable to split a large specification into smaller modules
    >>   (or to do the reverse operation). We do not think it is necessary at this
    >>   point to decide whether to split any particular document into smaller
    >>   modules, but it would be good to keep it as a possibility. We therefore
    >>   suggest the addition of the following sentence to the deliverable section.
    >> 
    >>> Also, to facilitate timely progress on the REC track and for
    >>> the sake of maintainability, based on consensus in the Working
    >>> Group, it may split or merge its deliverables.
    >> 
    >> 
    >> 
    >>   The reviewer's organization intends to participate in these groups:
    >>      - Publishing Working Group
    >> 
    >>   The reviewer's organization:
    >>      - intends to review drafts as they are published and send comments.
    >>      - intends to develop experimental implementations and send experience
    >>   reports.
    >>      - intends to develop products based on this work.
    >>      - intends to apply this technology in our operations.
    >> 
    >> 
    >>   Comments about the deliverables:
    >>      Vivliostyle develops Vivliostyle Viewer and Vivliostyle Formatter,
    >>   respecively an interactive UA and a pdf-generating UA, with support for
    >>   pagination and advanced typographic features based on CSS (and (X)HTML,
    >>   SVG, MathML...).
    >> 
    >>   Vivliostyle's product provide an answer to Pagination
    >>     https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2F2017%2FWD-pwp-ucr-20170309%2F%23pagination&data=02%7C01%7C%7C1153d04e26d84fb24f5a08d48c4bd065%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636287704672245455&sdata=rF3RdLiplHgNTUOQy%2BzKv1O56pL%2BRD2aK3WT8NGxqNY%3D&reserved=0
    >>   and also intends facilitate Off-lining and Archiving
    >>     https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2F2017%2FWD-pwp-ucr-20170309%2F%23onloffl&data=02%7C01%7C%7C1153d04e26d84fb24f5a08d48c4bd065%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636287704672245455&sdata=oOfXkaaagLaxeK0iW3Vovajf5Q20Eufvd0GOQ%2Bppzx4%3D&reserved=0
    >>     https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2F2017%2FWD-pwp-ucr-20170309%2F%23archiving&data=02%7C01%7C%7C1153d04e26d84fb24f5a08d48c4bd065%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636287704672245455&sdata=uesS5MhWmqSurrS9BsGMHCzmrfkM1QMFNxIgI6d8RlQ%3D&reserved=0
    >> 
    >>   We currently support ordinary web content as well as EPUB3 as input
    >>   formats, and intend to support EPUB4 and other (P)WP formats as they
    >>   appear.
    >> 
    >> 
    >>   Answers to this questionnaire can be set and changed at
    >>   https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2F2002%2F09%2Fwbs%2F33280%2Fpublwg%2F&data=02%7C01%7C%7C1153d04e26d84fb24f5a08d48c4bd065%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636287704672245455&sdata=ndpsEeCoC%2BWWFhM7v3IE3tYthxx%2FgiKq0iTLLF1pl4c%3D&reserved=0 until 2017-05-14.
    >> 
    >>    Regards,
    >> 
    >>    The Automatic WBS Mailer
    >> 
    >> 
    >> 
    >> 
    > 
    > 
    > 
    > 
    
    

Re: [wbs] response to 'Call for Review: Publishing Working Group Charter'

Source: public-digipub-ig@w3.org Mail Archives • marcos@marcosc.com (marcos@marcosc.com) • April 27, 2017 • Permalink



> On 27 Apr 2017, at 8:07 pm, Florian Rivoal <florian@rivoal.net> wrote:
> 
> Hi Leonard,
> 
> "a thorough review of these proposals" is probably the wrong phrasing. I agree that re-reading and re-tweaking the existing (P)WP documents would mostly be a waste of time. 
> 
> What I mean is that concrete proposals with normative prose need to be made, evaluated for their own merits, evaluated on how they fit into the rest of the platform, matured somewhat... in other words be incubated, **before** we can decide to put them on TR.

Oh, hai :) I made this suggestion also and gave a bunch of suggestions as to what to try (after extensive review of the use cases over a few weeks). 

I still think this community should do that before attempting standardization. 

> 
> Some members insist that this incubation must be done in Community Groups prior to the creation of the WG.

As Co-Chair of the WICG, totally! :) this is exactly what should happen. Specially given emerging tech like web manifest, service workers, and other PWA goodies. 

> I am (infamously?) not of that opinion, and think incubation is perfectly doable within a WG, so long as the WG takes this incubation seriously and has the necessary community (which we do have). So, I think we should charter the WG, do so without deliverables (because we have not yet incubated anything), then members should make proposals, those that seem half way reasonable should become EDs, and only once these EDs are sufficiently refined that we can get consensus that they not only address the right problem, but also address it the right way, then we can decide to put them on TR.
> 
> So yes, we should start actual work, but no, we should not put it on TR just yet, nor agree to do so before seeing and thinking hard about the actual proposals.

I wouldn't object to this - sounds good. Incubation and proof of concepts around PWA technology would be very informative and beneficial to the web at large. 

> 
> So based on this, I propose this new re-wording (keeping point 2 and 3 of my last mail unchanged):
> 
>> "The requirements, concepts, and suggested deliverables listed here have been derived from the preliminary considerations of the Digital Publishing Interest Group (see, for example, the PWP-UCR document) as well as the experiences from the EPUB 3.1 Working Group of the IDPF, especially its work on "Browser-friendly Manifestations". Informed (but not constrained) by these, concrete proposals now need to be drafted, incubated, and evaluated on their own merits and on how they fit in the rest of the platform. As they reach sufficient maturity and achieve consensus (See <a href="https://www.w3.org/Guide/standards-track/#criteria">Readiness Criteria</a> for guidelines), individual deliverables will be added. The detailed list, milestones, and updated publication schedules will be maintained on the <a href="@@@">group publication status page.</a> "
> 
> 
> Would that work better for you?
> 
> —Florian
> 
> 
>> On Apr 26, 2017, at 11:31, Leonard Rosenthol <lrosenth@adobe.com> wrote:
>> 
>> I, for one, have issues with the revised wording.  
>> 
>> I don’t believe that “a thorough review of these proposals…” is a mandatory requirement for us to move forward on the deliverables as we see them – in fact, I might argue that they would be an unwelcome distraction.   Mandating a process is not helpful.   The WG should focus on the deliverables – as the current Charter defines – and the process will work itself out.  
>> 
>> Leonard
>> 
>> On 4/25/17, 7:26 PM, "Florian Rivoal" <florian@rivoal.net> wrote:
>> 
>>   Hi,
>> 
>>   Yes, in broad lines, this change would remove my objection.
>> 
>>   Now, in details, I would write it a little differently.
>> 
>>   * Your phrasing suggest that we need to agree on all deliverables first, then start. Maybe this will happen, but more likely in my opinion, we may reach consensus quickly on some deliverables (e.g. DPUB-ARIA-2) and take a bit more time to figure out the concrete proposals for (P)WP and EPUB 4. Not having full agreement on everything should not block us from starting on the things where we do have agreement. So here's a suggestion:
>> 
>>   * As we cannot predict how long it will take to reach consensus on each deliverable, having milestones does not seem useful at this point, and may even be counter productive as it seems to suggest that publication should be date driven rather than consensus driven.
>> 
>>   Concretely, I would:
>> 
>>   1) tweak the text you proposed a little:
>> 
>>> "The requirements, concepts, and suggested deliverables listed here have been derived from the preliminary considerations of the Digital Publishing Interest Group (see, for example, the PWP-UCR document) as well as the experiences from the EPUB 3.1 Working Group of the IDPF, especially its work on "Browser-friendly Manifestations". One of the first tasks of the Working Group will be to make a thorough review of these proposals and how they fit with specifications from other Working Groups. As concrete proposals are made, reach sufficient maturity and achieve consensus (See <a href="https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FGuide%2Fstandards-track%2F%23criteria&data=02%7C01%7C%7C1153d04e26d84fb24f5a08d48c4bd065%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636287704672245455&sdata=dCNopqCO62SiZNieCwzggQFEJp5d6kOFRSW%2F3PBV3%2FQ%3D&reserved=0">Readiness Criteria</a> for guidelines), individual deliverables will be added. The detailed list, milestones, and updated publication schedules will be maintained on the <a href="@@@">group publication status page.</a> "
>> 
>> 
>>   2) Rename the "Recommendation-track Deliverables" to "Suggested Recommendation-track Deliverables", and delete the introductory sentence ("The working group will deliver .... ), since it is now covered by the paragraph we just discussed.
>> 
>>   3) In section 3.3, keep the introduction sentence and the face-to-face meetings, but remove the document milestones.
>> 
>> 
>>   Although the wording is a little different, I believe this is in agreement with the discussion we had during the AC meeting. Would this work for you?
>> 
>>   —Florian
>> 
>> 
>>> On Apr 25, 2017, at 16:06, Johnson, Rick <Rick.Johnson@ingramcontent.com> wrote:
>>> 
>>> Florian,
>>> 
>>> After our conversation at lunch, and assuming acceptance of the proposed changes already communicated around the objections raised by Daniel, does the below resolve your remaining objections?
>>> 
>>> -Rick
>>> 
>>> 
>>> 
>>> Replace in section 3. Deliverables, the first line:
>>>   “More detailed milestones and updated publication schedules are available on the group publication status page”
>>> 
>>> with the following:
>>> 
>>> "The requirements, concepts, deliverables, and milestones listed here have been derived from the preliminary considerations of the Digital Publishing Interest Group (see, for example, the PWP-UCR document) as well as the experiences from the EPUB 3.1 Working Group of the IDPF, especially its work on "Browser-friendly Manifestations". One of the first tasks of the Working Group will be to make a thorough review, achieve consensus on, and document the final list, milestones, and the content of the deliverables of the group.  The more detailed list, milestones, and updated publication schedules are available on the <a href="@@@">group publication status page.</a> "
>>> 
>>> 
>>> 
>>> On 4/18/17, 1:30 PM, "Florian Rivoal via WBS Mailer" <sysbot+wbs@w3.org> wrote:
>>> 
>>>  The following answers have been successfully submitted to 'Call for Review:
>>>  Publishing Working Group Charter' (Advisory Committee) for Vivliostyle Inc.
>>>  by Florian Rivoal.
>>> 
>>> 
>>>  The reviewer's organization suggests changes to this Charter, and only
>>>  supports the proposal if the changes are adopted [Formal Objection].
>>> 
>>>  Additional comments about the proposal:
>>>     Vivliostyle enthusiastically supports the creation of the Publishing
>>>  Working Group, its high level goals and scope, and the general format
>>>  proposed in the charter.
>>> 
>>>  However, we think there is an important flaw in the charter that must be
>>>  addressed first.
>>> 
>>>  Web Publications outlines a vision of convergence between digital
>>>  publications and the web. We absolutely support this vision, and hope to
>>>  contribute to its realization, both by participating in the WG and by
>>>  integrating these technologies in our products. Convergence of digital
>>>  publications and of the web is central to Vivliostyle's mission as a
>>>  company.
>>> 
>>>  However, to our reading, the existing Web Publications documents are a
>>>  manifesto and declaration of intent, not a concrete proposal to address the
>>>  problem.
>>> 
>>>  As such, we believe that (P)WP should be in scope for this working group,
>>>  and that concrete proposals to achieve this goal should be made, and when
>>>  consensual should be taken up as deliverables of this working group.
>>> 
>>>  We are however opposed to listing WP and PWP themselves as a REC track
>>>  deliverable with dated commitments.
>>> 
>>>  If "Web Publications" and "Packaged Web Publications" are meant to stay as
>>>  general documents outlining the vision independently of any concrete
>>>  implementable and testable incarnation, we think it would be much more
>>>  appropriate to publish them as WG Notes.
>>> 
>>>  If, as their proposed inclusion on the REC track suggests, they are meant
>>>  to be concrete technological proposals, we think the inclusion on the REC
>>>  track is premature, as we do not believe there is consensus on, or even a
>>>  general understanding of, what the concrete realization would be.
>>> 
>>>  Our concrete proposal is to:
>>> 
>>>  - List WP and PWP as deliverables as Working Group Notes and continue to
>>>  refine them as vision and requirements documents
>>> 
>>>  - Give the possibility to the group to take on new deliverables that help
>>>  achieve that vision when they are consensual, possibly by including
>>>  something along these lines in the charter (inspired by the CSSWG
>>>  charter):
>>> 
>>>> The WG may create new modules within its scope to fulfill or support the
>>>> vision outlined in WP and PWP. If no participant in the group believes a
>>>> proposed module is out of scope, and the group has consensus to add it,
>>>> the group may add a new module. If the participants who object sustain 
>>>> their objection after discussion, a re-charter to clarify the scope may
>>>  be
>>>> needed.
>>> 
>>>  ~~~
>>> 
>>>  Independently from this objection, we also make the following suggestion
>>>  (but do not oppose the creation of the WG on these grounds even if it was
>>>  rejected):
>>> 
>>>  For the sake of maintainability and timely progress along the REC track, it
>>>  is sometimes desirable to split a large specification into smaller modules
>>>  (or to do the reverse operation). We do not think it is necessary at this
>>>  point to decide whether to split any particular document into smaller
>>>  modules, but it would be good to keep it as a possibility. We therefore
>>>  suggest the addition of the following sentence to the deliverable section.
>>> 
>>>> Also, to facilitate timely progress on the REC track and for
>>>> the sake of maintainability, based on consensus in the Working
>>>> Group, it may split or merge its deliverables.
>>> 
>>> 
>>> 
>>>  The reviewer's organization intends to participate in these groups:
>>>     - Publishing Working Group
>>> 
>>>  The reviewer's organization:
>>>     - intends to review drafts as they are published and send comments.
>>>     - intends to develop experimental implementations and send experience
>>>  reports.
>>>     - intends to develop products based on this work.
>>>     - intends to apply this technology in our operations.
>>> 
>>> 
>>>  Comments about the deliverables:
>>>     Vivliostyle develops Vivliostyle Viewer and Vivliostyle Formatter,
>>>  respecively an interactive UA and a pdf-generating UA, with support for
>>>  pagination and advanced typographic features based on CSS (and (X)HTML,
>>>  SVG, MathML...).
>>> 
>>>  Vivliostyle's product provide an answer to Pagination
>>>    https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2F2017%2FWD-pwp-ucr-20170309%2F%23pagination&data=02%7C01%7C%7C1153d04e26d84fb24f5a08d48c4bd065%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636287704672245455&sdata=rF3RdLiplHgNTUOQy%2BzKv1O56pL%2BRD2aK3WT8NGxqNY%3D&reserved=0
>>>  and also intends facilitate Off-lining and Archiving
>>>    https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2F2017%2FWD-pwp-ucr-20170309%2F%23onloffl&data=02%7C01%7C%7C1153d04e26d84fb24f5a08d48c4bd065%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636287704672245455&sdata=oOfXkaaagLaxeK0iW3Vovajf5Q20Eufvd0GOQ%2Bppzx4%3D&reserved=0
>>>    https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2F2017%2FWD-pwp-ucr-20170309%2F%23archiving&data=02%7C01%7C%7C1153d04e26d84fb24f5a08d48c4bd065%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636287704672245455&sdata=uesS5MhWmqSurrS9BsGMHCzmrfkM1QMFNxIgI6d8RlQ%3D&reserved=0
>>> 
>>>  We currently support ordinary web content as well as EPUB3 as input
>>>  formats, and intend to support EPUB4 and other (P)WP formats as they
>>>  appear.
>>> 
>>> 
>>>  Answers to this questionnaire can be set and changed at
>>>  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2F2002%2F09%2Fwbs%2F33280%2Fpublwg%2F&data=02%7C01%7C%7C1153d04e26d84fb24f5a08d48c4bd065%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636287704672245455&sdata=ndpsEeCoC%2BWWFhM7v3IE3tYthxx%2FgiKq0iTLLF1pl4c%3D&reserved=0 until 2017-05-14.
>>> 
>>>   Regards,
>>> 
>>>   The Automatic WBS Mailer
>>> 
>>> 
>>> 
>>> 
>> 
>> 
>> 
>> 
> 
> 

[math-on-web] meeting agenda 2017/04/27

Source: public-mathonwebpages@w3.org Mail Archives • Peter Krautzberger (peter.krautzberger@mathjax.org) • April 27, 2017 • Permalink

Hi everyone,

Just a quick reminder that we're meeting today at 12:00 Eastern time
(GMT-04:00) via appear.in/mathonweb.

Agenda

* Updates from the a11y TF
* change CG meetings to topic-oriented cycling  (layout, accessibility,
notation)

Re: [wbs] response to 'Call for Review: Publishing Working Group Charter'

Source: public-digipub-ig@w3.org Mail Archives • Florian Rivoal (florian@rivoal.net) • April 27, 2017 • Permalink

Hi Leonard,

"a thorough review of these proposals" is probably the wrong phrasing. I agree that re-reading and re-tweaking the existing (P)WP documents would mostly be a waste of time. 

What I mean is that concrete proposals with normative prose need to be made, evaluated for their own merits, evaluated on how they fit into the rest of the platform, matured somewhat... in other words be incubated, **before** we can decide to put them on TR.

Some members insist that this incubation must be done in Community Groups prior to the creation of the WG. I am (infamously?) not of that opinion, and think incubation is perfectly doable within a WG, so long as the WG takes this incubation seriously and has the necessary community (which we do have). So, I think we should charter the WG, do so without deliverables (because we have not yet incubated anything), then members should make proposals, those that seem half way reasonable should become EDs, and only once these EDs are sufficiently refined that we can get consensus that they not only address the right problem, but also address it the right way, then we can decide to put them on TR.

So yes, we should start actual work, but no, we should not put it on TR just yet, nor agree to do so before seeing and thinking hard about the actual proposals.

So based on this, I propose this new re-wording (keeping point 2 and 3 of my last mail unchanged):

> "The requirements, concepts, and suggested deliverables listed here have been derived from the preliminary considerations of the Digital Publishing Interest Group (see, for example, the PWP-UCR document) as well as the experiences from the EPUB 3.1 Working Group of the IDPF, especially its work on "Browser-friendly Manifestations". Informed (but not constrained) by these, concrete proposals now need to be drafted, incubated, and evaluated on their own merits and on how they fit in the rest of the platform. As they reach sufficient maturity and achieve consensus (See <a href="https://www.w3.org/Guide/standards-track/#criteria">Readiness Criteria</a> for guidelines), individual deliverables will be added. The detailed list, milestones, and updated publication schedules will be maintained on the <a href="@@@">group publication status page.</a> "


Would that work better for you?

—Florian


> On Apr 26, 2017, at 11:31, Leonard Rosenthol <lrosenth@adobe.com> wrote:
> 
> I, for one, have issues with the revised wording.  
> 
> I don’t believe that “a thorough review of these proposals…” is a mandatory requirement for us to move forward on the deliverables as we see them – in fact, I might argue that they would be an unwelcome distraction.   Mandating a process is not helpful.   The WG should focus on the deliverables – as the current Charter defines – and the process will work itself out.  
> 
> Leonard
> 
> On 4/25/17, 7:26 PM, "Florian Rivoal" <florian@rivoal.net> wrote:
> 
>    Hi,
> 
>    Yes, in broad lines, this change would remove my objection.
> 
>    Now, in details, I would write it a little differently.
> 
>    * Your phrasing suggest that we need to agree on all deliverables first, then start. Maybe this will happen, but more likely in my opinion, we may reach consensus quickly on some deliverables (e.g. DPUB-ARIA-2) and take a bit more time to figure out the concrete proposals for (P)WP and EPUB 4. Not having full agreement on everything should not block us from starting on the things where we do have agreement. So here's a suggestion:
> 
>    * As we cannot predict how long it will take to reach consensus on each deliverable, having milestones does not seem useful at this point, and may even be counter productive as it seems to suggest that publication should be date driven rather than consensus driven.
> 
>    Concretely, I would:
> 
>    1) tweak the text you proposed a little:
> 
>> "The requirements, concepts, and suggested deliverables listed here have been derived from the preliminary considerations of the Digital Publishing Interest Group (see, for example, the PWP-UCR document) as well as the experiences from the EPUB 3.1 Working Group of the IDPF, especially its work on "Browser-friendly Manifestations". One of the first tasks of the Working Group will be to make a thorough review of these proposals and how they fit with specifications from other Working Groups. As concrete proposals are made, reach sufficient maturity and achieve consensus (See <a href="https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FGuide%2Fstandards-track%2F%23criteria&data=02%7C01%7C%7C1153d04e26d84fb24f5a08d48c4bd065%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636287704672245455&sdata=dCNopqCO62SiZNieCwzggQFEJp5d6kOFRSW%2F3PBV3%2FQ%3D&reserved=0">Readiness Criteria</a> for guidelines), individual deliverables will be added. The detailed list, milestones, and updated publication schedules will be maintained on the <a href="@@@">group publication status page.</a> "
> 
> 
>    2) Rename the "Recommendation-track Deliverables" to "Suggested Recommendation-track Deliverables", and delete the introductory sentence ("The working group will deliver .... ), since it is now covered by the paragraph we just discussed.
> 
>    3) In section 3.3, keep the introduction sentence and the face-to-face meetings, but remove the document milestones.
> 
> 
>    Although the wording is a little different, I believe this is in agreement with the discussion we had during the AC meeting. Would this work for you?
> 
>    —Florian
> 
> 
>> On Apr 25, 2017, at 16:06, Johnson, Rick <Rick.Johnson@ingramcontent.com> wrote:
>> 
>> Florian,
>> 
>> After our conversation at lunch, and assuming acceptance of the proposed changes already communicated around the objections raised by Daniel, does the below resolve your remaining objections?
>> 
>> -Rick
>> 
>> 
>> 
>> Replace in section 3. Deliverables, the first line:
>>    “More detailed milestones and updated publication schedules are available on the group publication status page”
>> 
>> with the following:
>> 
>> "The requirements, concepts, deliverables, and milestones listed here have been derived from the preliminary considerations of the Digital Publishing Interest Group (see, for example, the PWP-UCR document) as well as the experiences from the EPUB 3.1 Working Group of the IDPF, especially its work on "Browser-friendly Manifestations". One of the first tasks of the Working Group will be to make a thorough review, achieve consensus on, and document the final list, milestones, and the content of the deliverables of the group.  The more detailed list, milestones, and updated publication schedules are available on the <a href="@@@">group publication status page.</a> "
>> 
>> 
>> 
>> On 4/18/17, 1:30 PM, "Florian Rivoal via WBS Mailer" <sysbot+wbs@w3.org> wrote:
>> 
>>   The following answers have been successfully submitted to 'Call for Review:
>>   Publishing Working Group Charter' (Advisory Committee) for Vivliostyle Inc.
>>   by Florian Rivoal.
>> 
>> 
>>   The reviewer's organization suggests changes to this Charter, and only
>>   supports the proposal if the changes are adopted [Formal Objection].
>> 
>>   Additional comments about the proposal:
>>      Vivliostyle enthusiastically supports the creation of the Publishing
>>   Working Group, its high level goals and scope, and the general format
>>   proposed in the charter.
>> 
>>   However, we think there is an important flaw in the charter that must be
>>   addressed first.
>> 
>>   Web Publications outlines a vision of convergence between digital
>>   publications and the web. We absolutely support this vision, and hope to
>>   contribute to its realization, both by participating in the WG and by
>>   integrating these technologies in our products. Convergence of digital
>>   publications and of the web is central to Vivliostyle's mission as a
>>   company.
>> 
>>   However, to our reading, the existing Web Publications documents are a
>>   manifesto and declaration of intent, not a concrete proposal to address the
>>   problem.
>> 
>>   As such, we believe that (P)WP should be in scope for this working group,
>>   and that concrete proposals to achieve this goal should be made, and when
>>   consensual should be taken up as deliverables of this working group.
>> 
>>   We are however opposed to listing WP and PWP themselves as a REC track
>>   deliverable with dated commitments.
>> 
>>   If "Web Publications" and "Packaged Web Publications" are meant to stay as
>>   general documents outlining the vision independently of any concrete
>>   implementable and testable incarnation, we think it would be much more
>>   appropriate to publish them as WG Notes.
>> 
>>   If, as their proposed inclusion on the REC track suggests, they are meant
>>   to be concrete technological proposals, we think the inclusion on the REC
>>   track is premature, as we do not believe there is consensus on, or even a
>>   general understanding of, what the concrete realization would be.
>> 
>>   Our concrete proposal is to:
>> 
>>   - List WP and PWP as deliverables as Working Group Notes and continue to
>>   refine them as vision and requirements documents
>> 
>>   - Give the possibility to the group to take on new deliverables that help
>>   achieve that vision when they are consensual, possibly by including
>>   something along these lines in the charter (inspired by the CSSWG
>>   charter):
>> 
>>> The WG may create new modules within its scope to fulfill or support the
>>> vision outlined in WP and PWP. If no participant in the group believes a
>>> proposed module is out of scope, and the group has consensus to add it,
>>> the group may add a new module. If the participants who object sustain 
>>> their objection after discussion, a re-charter to clarify the scope may
>>   be
>>> needed.
>> 
>>   ~~~
>> 
>>   Independently from this objection, we also make the following suggestion
>>   (but do not oppose the creation of the WG on these grounds even if it was
>>   rejected):
>> 
>>   For the sake of maintainability and timely progress along the REC track, it
>>   is sometimes desirable to split a large specification into smaller modules
>>   (or to do the reverse operation). We do not think it is necessary at this
>>   point to decide whether to split any particular document into smaller
>>   modules, but it would be good to keep it as a possibility. We therefore
>>   suggest the addition of the following sentence to the deliverable section.
>> 
>>> Also, to facilitate timely progress on the REC track and for
>>> the sake of maintainability, based on consensus in the Working
>>> Group, it may split or merge its deliverables.
>> 
>> 
>> 
>>   The reviewer's organization intends to participate in these groups:
>>      - Publishing Working Group
>> 
>>   The reviewer's organization:
>>      - intends to review drafts as they are published and send comments.
>>      - intends to develop experimental implementations and send experience
>>   reports.
>>      - intends to develop products based on this work.
>>      - intends to apply this technology in our operations.
>> 
>> 
>>   Comments about the deliverables:
>>      Vivliostyle develops Vivliostyle Viewer and Vivliostyle Formatter,
>>   respecively an interactive UA and a pdf-generating UA, with support for
>>   pagination and advanced typographic features based on CSS (and (X)HTML,
>>   SVG, MathML...).
>> 
>>   Vivliostyle's product provide an answer to Pagination
>>     https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2F2017%2FWD-pwp-ucr-20170309%2F%23pagination&data=02%7C01%7C%7C1153d04e26d84fb24f5a08d48c4bd065%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636287704672245455&sdata=rF3RdLiplHgNTUOQy%2BzKv1O56pL%2BRD2aK3WT8NGxqNY%3D&reserved=0
>>   and also intends facilitate Off-lining and Archiving
>>     https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2F2017%2FWD-pwp-ucr-20170309%2F%23onloffl&data=02%7C01%7C%7C1153d04e26d84fb24f5a08d48c4bd065%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636287704672245455&sdata=oOfXkaaagLaxeK0iW3Vovajf5Q20Eufvd0GOQ%2Bppzx4%3D&reserved=0
>>     https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2F2017%2FWD-pwp-ucr-20170309%2F%23archiving&data=02%7C01%7C%7C1153d04e26d84fb24f5a08d48c4bd065%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636287704672245455&sdata=uesS5MhWmqSurrS9BsGMHCzmrfkM1QMFNxIgI6d8RlQ%3D&reserved=0
>> 
>>   We currently support ordinary web content as well as EPUB3 as input
>>   formats, and intend to support EPUB4 and other (P)WP formats as they
>>   appear.
>> 
>> 
>>   Answers to this questionnaire can be set and changed at
>>   https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2F2002%2F09%2Fwbs%2F33280%2Fpublwg%2F&data=02%7C01%7C%7C1153d04e26d84fb24f5a08d48c4bd065%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636287704672245455&sdata=ndpsEeCoC%2BWWFhM7v3IE3tYthxx%2FgiKq0iTLLF1pl4c%3D&reserved=0 until 2017-05-14.
>> 
>>    Regards,
>> 
>>    The Automatic WBS Mailer
>> 
>> 
>> 
>> 
> 
> 
> 
> 

Re: MathML spec re: Obsoleting some specifications

Source: www-math@w3.org Mail Archives • Peter Krautzberger (peter.krautzberger@mathjax.org) • April 27, 2017 • Permalink

Hi,

Chaals wrote:

> The implication is effectively that it gets a banner, saying we think you
should be looking at something else if you want to implement MathML.

(Where "something else" refers to MathML 3 as opposed to MathML 1 and 2.)

This sounds like a very good idea.

> If there is some significant level of MathML 2 support in deployed stuff
that people use, that isn't matched by MathML 3 support then it may make
sense to keep both [...]

>From our experience at MathJax, there are extremely few cases of MathML 2
content that is not compatible with MathML 3 (and causes issues). My
unsubstantiated estimate would be that we have one case per year appearing
on our radar. I can't recall any of these being a major problem to resolve.

So marking MathML 1 and 2 as obsolete seems very sensible.

Best,
Peter.
-- 

Peter Krautzberger, MathJax Manager

mathjax.org <http://www.mathjax.org/> | fb.com/mathjax | @mathjax
<http://twitter.com/mathjax>

Support MathJax - Become a Sponsor!
<http://www.mathjax.org/sponsors/mathjax-sponsorship-program/>


On Thu, Apr 27, 2017 at 6:22 AM, <chaals@yandex-team.ru> wrote:

> Dear mathemagicians and others,
>
> this discussion is taking place on the W3C TAG mailing list, and your
> input might be helpful there...
>
> cheers
>
> Chaals
>
> -------- Пересылаемое сообщение  --------
> 27.04.2017, 00:48, "chaals@yandex-team.ru" <chaals@yandex-team.ru>:
>
> Hi David,
>
> 27.04.2017, 00:23, "David Carlisle" <davidc@nag.co.uk>:
> >   > MathML 1 and 2 - there is a version 3
> >
> >  As you note the Math WG is currently in cold storage however you could
> >  flag this on the www-math list.
>
> I'll send a pointer to this discussion onto the www-math list.
>
> [...thanks for explaining in more detail...]
> >  That would leave MathML 2.0 2nd edition and MathML 3.0 2nd edition.
> >
> >  In these versions MathML 2 is with only very minor exceptions a
> >  compatible subset of MathML 3, and so it possibly makes sense to leave
> >  that so any implementations that don't implement the additional features
> >  can claim they support MathML 2 rather than support some MathML 3
> >  subset, but they could probably claim that anyway. I'm not clear to be
> >  honest what are the implications of marking a spec obsolete, is it just
> >  that it gets a banner added in place saying that it is obsolete (and
> >  pointing at the newer spec) or is there more to it?
>
> The implication is effectively that it gets a banner, saying we think you
> should be looking at something else if you want to implement MathML. The
> specs are still formally W3C Recommendations, and the text is of course
> available, so if anyone wants to check their conformance specifically to
> e.g. MathML 1.0 they can do so, and there is a recognition that
> "obsoletion" might happen prematurely, e.g. because for some reason a whole
> new industry develops around MathML 1 - so it is meant to be relatively
> straightforward to reverse in such cases.
>
> If there is some significant level of MathML 2 support in deployed stuff
> that people use, that isn't matched by MathML 3 support then it may make
> sense to keep both of them, in the same way that Martin noted for the XSLT
> example.
>
> cheers, and thanks for the input. I hope we get more from people who
> specifically know MathML…
>
> chaals
>
> --
> Charles McCathie Nevile - standards - Yandex
> chaals@yandex-team.ru - - - Find more at http://yandex.com
> -------- Конец пересылаемого сообщения --------
>
> --
> Charles McCathie Nevile - standards - Yandex
> chaals@yandex-team.ru - - - Find more at http://yandex.com
>
>

MathML spec re: Obsoleting some specifications

Source: www-math@w3.org Mail Archives • chaals@yandex-team.ru (chaals@yandex-team.ru) • April 27, 2017 • Permalink

Dear mathemagicians and others,

this discussion is taking place on the W3C TAG mailing list, and your input might be helpful there...

cheers

Chaals

-------- Пересылаемое сообщение  --------
27.04.2017, 00:48, "chaals@yandex-team.ru" <chaals@yandex-team.ru>:

Hi David,

27.04.2017, 00:23, "David Carlisle" <davidc@nag.co.uk>:
>   > MathML 1 and 2 - there is a version 3
>
>  As you note the Math WG is currently in cold storage however you could
>  flag this on the www-math list.

I'll send a pointer to this discussion onto the www-math list.

[...thanks for explaining in more detail...]
>  That would leave MathML 2.0 2nd edition and MathML 3.0 2nd edition.
>
>  In these versions MathML 2 is with only very minor exceptions a
>  compatible subset of MathML 3, and so it possibly makes sense to leave
>  that so any implementations that don't implement the additional features
>  can claim they support MathML 2 rather than support some MathML 3
>  subset, but they could probably claim that anyway. I'm not clear to be
>  honest what are the implications of marking a spec obsolete, is it just
>  that it gets a banner added in place saying that it is obsolete (and
>  pointing at the newer spec) or is there more to it?

The implication is effectively that it gets a banner, saying we think you should be looking at something else if you want to implement MathML. The specs are still formally W3C Recommendations, and the text is of course available, so if anyone wants to check their conformance specifically to e.g. MathML 1.0 they can do so, and there is a recognition that "obsoletion" might happen prematurely, e.g. because for some reason a whole new industry develops around MathML 1 - so it is meant to be relatively straightforward to reverse in such cases.

If there is some significant level of MathML 2 support in deployed stuff that people use, that isn't matched by MathML 3 support then it may make sense to keep both of them, in the same way that Martin noted for the XSLT example.

cheers, and thanks for the input. I hope we get more from people who specifically know MathML…

chaals

--
Charles McCathie Nevile - standards - Yandex
chaals@yandex-team.ru - - - Find more at http://yandex.com
-------- Конец пересылаемого сообщения --------

-- 
Charles McCathie Nevile - standards - Yandex
chaals@yandex-team.ru - - - Find more at http://yandex.com

Re: [wbs] response to 'Call for Review: Publishing Working Group Charter'

Source: public-digipub-ig@w3.org Mail Archives • Leonard Rosenthol (lrosenth@adobe.com) • April 26, 2017 • Permalink

I, for one, have issues with the revised wording.  

I don’t believe that “a thorough review of these proposals…” is a mandatory requirement for us to move forward on the deliverables as we see them – in fact, I might argue that they would be an unwelcome distraction.   Mandating a process is not helpful.   The WG should focus on the deliverables – as the current Charter defines – and the process will work itself out.  

Leonard

On 4/25/17, 7:26 PM, "Florian Rivoal" <florian@rivoal.net> wrote:

    Hi,
    
    Yes, in broad lines, this change would remove my objection.
    
    Now, in details, I would write it a little differently.
    
    * Your phrasing suggest that we need to agree on all deliverables first, then start. Maybe this will happen, but more likely in my opinion, we may reach consensus quickly on some deliverables (e.g. DPUB-ARIA-2) and take a bit more time to figure out the concrete proposals for (P)WP and EPUB 4. Not having full agreement on everything should not block us from starting on the things where we do have agreement. So here's a suggestion:
    
    * As we cannot predict how long it will take to reach consensus on each deliverable, having milestones does not seem useful at this point, and may even be counter productive as it seems to suggest that publication should be date driven rather than consensus driven.
    
    Concretely, I would:
    
    1) tweak the text you proposed a little:
    
    > "The requirements, concepts, and suggested deliverables listed here have been derived from the preliminary considerations of the Digital Publishing Interest Group (see, for example, the PWP-UCR document) as well as the experiences from the EPUB 3.1 Working Group of the IDPF, especially its work on "Browser-friendly Manifestations". One of the first tasks of the Working Group will be to make a thorough review of these proposals and how they fit with specifications from other Working Groups. As concrete proposals are made, reach sufficient maturity and achieve consensus (See <a href="https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FGuide%2Fstandards-track%2F%23criteria&data=02%7C01%7C%7C1153d04e26d84fb24f5a08d48c4bd065%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636287704672245455&sdata=dCNopqCO62SiZNieCwzggQFEJp5d6kOFRSW%2F3PBV3%2FQ%3D&reserved=0">Readiness Criteria</a> for guidelines), individual deliverables will be added. The detailed list, milestones, and updated publication schedules will be maintained on the <a href="@@@">group publication status page.</a> "
    
    
    2) Rename the "Recommendation-track Deliverables" to "Suggested Recommendation-track Deliverables", and delete the introductory sentence ("The working group will deliver .... ), since it is now covered by the paragraph we just discussed.
    
    3) In section 3.3, keep the introduction sentence and the face-to-face meetings, but remove the document milestones.
    
    
    Although the wording is a little different, I believe this is in agreement with the discussion we had during the AC meeting. Would this work for you?
    
    —Florian
    
    
    > On Apr 25, 2017, at 16:06, Johnson, Rick <Rick.Johnson@ingramcontent.com> wrote:
    > 
    > Florian,
    > 
    > After our conversation at lunch, and assuming acceptance of the proposed changes already communicated around the objections raised by Daniel, does the below resolve your remaining objections?
    > 
    > -Rick
    > 
    > 
    > 
    > Replace in section 3. Deliverables, the first line:
    >     “More detailed milestones and updated publication schedules are available on the group publication status page”
    > 
    > with the following:
    > 
    > "The requirements, concepts, deliverables, and milestones listed here have been derived from the preliminary considerations of the Digital Publishing Interest Group (see, for example, the PWP-UCR document) as well as the experiences from the EPUB 3.1 Working Group of the IDPF, especially its work on "Browser-friendly Manifestations". One of the first tasks of the Working Group will be to make a thorough review, achieve consensus on, and document the final list, milestones, and the content of the deliverables of the group.  The more detailed list, milestones, and updated publication schedules are available on the <a href="@@@">group publication status page.</a> "
    > 
    > 
    > 
    > On 4/18/17, 1:30 PM, "Florian Rivoal via WBS Mailer" <sysbot+wbs@w3.org> wrote:
    > 
    >    The following answers have been successfully submitted to 'Call for Review:
    >    Publishing Working Group Charter' (Advisory Committee) for Vivliostyle Inc.
    >    by Florian Rivoal.
    > 
    > 
    >    The reviewer's organization suggests changes to this Charter, and only
    >    supports the proposal if the changes are adopted [Formal Objection].
    > 
    >    Additional comments about the proposal:
    >       Vivliostyle enthusiastically supports the creation of the Publishing
    >    Working Group, its high level goals and scope, and the general format
    >    proposed in the charter.
    > 
    >    However, we think there is an important flaw in the charter that must be
    >    addressed first.
    > 
    >    Web Publications outlines a vision of convergence between digital
    >    publications and the web. We absolutely support this vision, and hope to
    >    contribute to its realization, both by participating in the WG and by
    >    integrating these technologies in our products. Convergence of digital
    >    publications and of the web is central to Vivliostyle's mission as a
    >    company.
    > 
    >    However, to our reading, the existing Web Publications documents are a
    >    manifesto and declaration of intent, not a concrete proposal to address the
    >    problem.
    > 
    >    As such, we believe that (P)WP should be in scope for this working group,
    >    and that concrete proposals to achieve this goal should be made, and when
    >    consensual should be taken up as deliverables of this working group.
    > 
    >    We are however opposed to listing WP and PWP themselves as a REC track
    >    deliverable with dated commitments.
    > 
    >    If "Web Publications" and "Packaged Web Publications" are meant to stay as
    >    general documents outlining the vision independently of any concrete
    >    implementable and testable incarnation, we think it would be much more
    >    appropriate to publish them as WG Notes.
    > 
    >    If, as their proposed inclusion on the REC track suggests, they are meant
    >    to be concrete technological proposals, we think the inclusion on the REC
    >    track is premature, as we do not believe there is consensus on, or even a
    >    general understanding of, what the concrete realization would be.
    > 
    >    Our concrete proposal is to:
    > 
    >    - List WP and PWP as deliverables as Working Group Notes and continue to
    >    refine them as vision and requirements documents
    > 
    >    - Give the possibility to the group to take on new deliverables that help
    >    achieve that vision when they are consensual, possibly by including
    >    something along these lines in the charter (inspired by the CSSWG
    >    charter):
    > 
    >> The WG may create new modules within its scope to fulfill or support the
    >> vision outlined in WP and PWP. If no participant in the group believes a
    >> proposed module is out of scope, and the group has consensus to add it,
    >> the group may add a new module. If the participants who object sustain 
    >> their objection after discussion, a re-charter to clarify the scope may
    >    be
    >> needed.
    > 
    >    ~~~
    > 
    >    Independently from this objection, we also make the following suggestion
    >    (but do not oppose the creation of the WG on these grounds even if it was
    >    rejected):
    > 
    >    For the sake of maintainability and timely progress along the REC track, it
    >    is sometimes desirable to split a large specification into smaller modules
    >    (or to do the reverse operation). We do not think it is necessary at this
    >    point to decide whether to split any particular document into smaller
    >    modules, but it would be good to keep it as a possibility. We therefore
    >    suggest the addition of the following sentence to the deliverable section.
    > 
    >> Also, to facilitate timely progress on the REC track and for
    >> the sake of maintainability, based on consensus in the Working
    >> Group, it may split or merge its deliverables.
    > 
    > 
    > 
    >    The reviewer's organization intends to participate in these groups:
    >       - Publishing Working Group
    > 
    >    The reviewer's organization:
    >       - intends to review drafts as they are published and send comments.
    >       - intends to develop experimental implementations and send experience
    >    reports.
    >       - intends to develop products based on this work.
    >       - intends to apply this technology in our operations.
    > 
    > 
    >    Comments about the deliverables:
    >       Vivliostyle develops Vivliostyle Viewer and Vivliostyle Formatter,
    >    respecively an interactive UA and a pdf-generating UA, with support for
    >    pagination and advanced typographic features based on CSS (and (X)HTML,
    >    SVG, MathML...).
    > 
    >    Vivliostyle's product provide an answer to Pagination
    >      https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2F2017%2FWD-pwp-ucr-20170309%2F%23pagination&data=02%7C01%7C%7C1153d04e26d84fb24f5a08d48c4bd065%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636287704672245455&sdata=rF3RdLiplHgNTUOQy%2BzKv1O56pL%2BRD2aK3WT8NGxqNY%3D&reserved=0
    >    and also intends facilitate Off-lining and Archiving
    >      https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2F2017%2FWD-pwp-ucr-20170309%2F%23onloffl&data=02%7C01%7C%7C1153d04e26d84fb24f5a08d48c4bd065%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636287704672245455&sdata=oOfXkaaagLaxeK0iW3Vovajf5Q20Eufvd0GOQ%2Bppzx4%3D&reserved=0
    >      https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2F2017%2FWD-pwp-ucr-20170309%2F%23archiving&data=02%7C01%7C%7C1153d04e26d84fb24f5a08d48c4bd065%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636287704672245455&sdata=uesS5MhWmqSurrS9BsGMHCzmrfkM1QMFNxIgI6d8RlQ%3D&reserved=0
    > 
    >    We currently support ordinary web content as well as EPUB3 as input
    >    formats, and intend to support EPUB4 and other (P)WP formats as they
    >    appear.
    > 
    > 
    >    Answers to this questionnaire can be set and changed at
    >    https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2F2002%2F09%2Fwbs%2F33280%2Fpublwg%2F&data=02%7C01%7C%7C1153d04e26d84fb24f5a08d48c4bd065%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636287704672245455&sdata=ndpsEeCoC%2BWWFhM7v3IE3tYthxx%2FgiKq0iTLLF1pl4c%3D&reserved=0 until 2017-05-14.
    > 
    >     Regards,
    > 
    >     The Automatic WBS Mailer
    > 
    > 
    > 
    > 
    
    
    

Re: [wbs] response to 'Call for Review: Publishing Working Group Charter'

Source: public-digipub-ig@w3.org Mail Archives • Florian Rivoal (florian@rivoal.net) • April 26, 2017 • Permalink

Hi,

Yes, in broad lines, this change would remove my objection.

Now, in details, I would write it a little differently.

* Your phrasing suggest that we need to agree on all deliverables first, then start. Maybe this will happen, but more likely in my opinion, we may reach consensus quickly on some deliverables (e.g. DPUB-ARIA-2) and take a bit more time to figure out the concrete proposals for (P)WP and EPUB 4. Not having full agreement on everything should not block us from starting on the things where we do have agreement. So here's a suggestion:

* As we cannot predict how long it will take to reach consensus on each deliverable, having milestones does not seem useful at this point, and may even be counter productive as it seems to suggest that publication should be date driven rather than consensus driven.

Concretely, I would:

1) tweak the text you proposed a little:

> "The requirements, concepts, and suggested deliverables listed here have been derived from the preliminary considerations of the Digital Publishing Interest Group (see, for example, the PWP-UCR document) as well as the experiences from the EPUB 3.1 Working Group of the IDPF, especially its work on "Browser-friendly Manifestations". One of the first tasks of the Working Group will be to make a thorough review of these proposals and how they fit with specifications from other Working Groups. As concrete proposals are made, reach sufficient maturity and achieve consensus (See <a href="https://www.w3.org/Guide/standards-track/#criteria">Readiness Criteria</a> for guidelines), individual deliverables will be added. The detailed list, milestones, and updated publication schedules will be maintained on the <a href="@@@">group publication status page.</a> "


2) Rename the "Recommendation-track Deliverables" to "Suggested Recommendation-track Deliverables", and delete the introductory sentence ("The working group will deliver .... ), since it is now covered by the paragraph we just discussed.

3) In section 3.3, keep the introduction sentence and the face-to-face meetings, but remove the document milestones.


Although the wording is a little different, I believe this is in agreement with the discussion we had during the AC meeting. Would this work for you?

—Florian


> On Apr 25, 2017, at 16:06, Johnson, Rick <Rick.Johnson@ingramcontent.com> wrote:
> 
> Florian,
> 
> After our conversation at lunch, and assuming acceptance of the proposed changes already communicated around the objections raised by Daniel, does the below resolve your remaining objections?
> 
> -Rick
> 
> 
> 
> Replace in section 3. Deliverables, the first line:
>     “More detailed milestones and updated publication schedules are available on the group publication status page”
> 
> with the following:
> 
> "The requirements, concepts, deliverables, and milestones listed here have been derived from the preliminary considerations of the Digital Publishing Interest Group (see, for example, the PWP-UCR document) as well as the experiences from the EPUB 3.1 Working Group of the IDPF, especially its work on "Browser-friendly Manifestations". One of the first tasks of the Working Group will be to make a thorough review, achieve consensus on, and document the final list, milestones, and the content of the deliverables of the group.  The more detailed list, milestones, and updated publication schedules are available on the <a href="@@@">group publication status page.</a> "
> 
> 
> 
> On 4/18/17, 1:30 PM, "Florian Rivoal via WBS Mailer" <sysbot+wbs@w3.org> wrote:
> 
>    The following answers have been successfully submitted to 'Call for Review:
>    Publishing Working Group Charter' (Advisory Committee) for Vivliostyle Inc.
>    by Florian Rivoal.
> 
> 
>    The reviewer's organization suggests changes to this Charter, and only
>    supports the proposal if the changes are adopted [Formal Objection].
> 
>    Additional comments about the proposal:
>       Vivliostyle enthusiastically supports the creation of the Publishing
>    Working Group, its high level goals and scope, and the general format
>    proposed in the charter.
> 
>    However, we think there is an important flaw in the charter that must be
>    addressed first.
> 
>    Web Publications outlines a vision of convergence between digital
>    publications and the web. We absolutely support this vision, and hope to
>    contribute to its realization, both by participating in the WG and by
>    integrating these technologies in our products. Convergence of digital
>    publications and of the web is central to Vivliostyle's mission as a
>    company.
> 
>    However, to our reading, the existing Web Publications documents are a
>    manifesto and declaration of intent, not a concrete proposal to address the
>    problem.
> 
>    As such, we believe that (P)WP should be in scope for this working group,
>    and that concrete proposals to achieve this goal should be made, and when
>    consensual should be taken up as deliverables of this working group.
> 
>    We are however opposed to listing WP and PWP themselves as a REC track
>    deliverable with dated commitments.
> 
>    If "Web Publications" and "Packaged Web Publications" are meant to stay as
>    general documents outlining the vision independently of any concrete
>    implementable and testable incarnation, we think it would be much more
>    appropriate to publish them as WG Notes.
> 
>    If, as their proposed inclusion on the REC track suggests, they are meant
>    to be concrete technological proposals, we think the inclusion on the REC
>    track is premature, as we do not believe there is consensus on, or even a
>    general understanding of, what the concrete realization would be.
> 
>    Our concrete proposal is to:
> 
>    - List WP and PWP as deliverables as Working Group Notes and continue to
>    refine them as vision and requirements documents
> 
>    - Give the possibility to the group to take on new deliverables that help
>    achieve that vision when they are consensual, possibly by including
>    something along these lines in the charter (inspired by the CSSWG
>    charter):
> 
>> The WG may create new modules within its scope to fulfill or support the
>> vision outlined in WP and PWP. If no participant in the group believes a
>> proposed module is out of scope, and the group has consensus to add it,
>> the group may add a new module. If the participants who object sustain 
>> their objection after discussion, a re-charter to clarify the scope may
>    be
>> needed.
> 
>    ~~~
> 
>    Independently from this objection, we also make the following suggestion
>    (but do not oppose the creation of the WG on these grounds even if it was
>    rejected):
> 
>    For the sake of maintainability and timely progress along the REC track, it
>    is sometimes desirable to split a large specification into smaller modules
>    (or to do the reverse operation). We do not think it is necessary at this
>    point to decide whether to split any particular document into smaller
>    modules, but it would be good to keep it as a possibility. We therefore
>    suggest the addition of the following sentence to the deliverable section.
> 
>> Also, to facilitate timely progress on the REC track and for
>> the sake of maintainability, based on consensus in the Working
>> Group, it may split or merge its deliverables.
> 
> 
> 
>    The reviewer's organization intends to participate in these groups:
>       - Publishing Working Group
> 
>    The reviewer's organization:
>       - intends to review drafts as they are published and send comments.
>       - intends to develop experimental implementations and send experience
>    reports.
>       - intends to develop products based on this work.
>       - intends to apply this technology in our operations.
> 
> 
>    Comments about the deliverables:
>       Vivliostyle develops Vivliostyle Viewer and Vivliostyle Formatter,
>    respecively an interactive UA and a pdf-generating UA, with support for
>    pagination and advanced typographic features based on CSS (and (X)HTML,
>    SVG, MathML...).
> 
>    Vivliostyle's product provide an answer to Pagination
>      https://www.w3.org/TR/2017/WD-pwp-ucr-20170309/#pagination
>    and also intends facilitate Off-lining and Archiving
>      https://www.w3.org/TR/2017/WD-pwp-ucr-20170309/#onloffl
>      https://www.w3.org/TR/2017/WD-pwp-ucr-20170309/#archiving
> 
>    We currently support ordinary web content as well as EPUB3 as input
>    formats, and intend to support EPUB4 and other (P)WP formats as they
>    appear.
> 
> 
>    Answers to this questionnaire can be set and changed at
>    https://www.w3.org/2002/09/wbs/33280/publwg/ until 2017-05-14.
> 
>     Regards,
> 
>     The Automatic WBS Mailer
> 
> 
> 
> 

RE: Meeting today

Source: public-mathonwebpages@w3.org Mail Archives • Daniel Marques (dani@wiris.com) • April 25, 2017 • Permalink

Sorry, I’ve done a mistake and the second link should be
http://www.wiris.net/demo/editor/tests/en/test.html



Dani



*From:* Kevin Cheung [mailto:KEVINCHEUNG@CUNET.CARLETON.CA]
*Sent:* martes, 25 de abril de 2017 12:45
*To:* Daniel Marques
*Subject:* Re: Meeting today



HI Daniel,



I got the following error from the demo link:
Forbidden

You don't have permission to access /editor/demo on this server.



On Apr 25, 2017, at 6:05 AM, Daniel Marques <dani@wiris.com> wrote:



Hi Charles,



That’s true I owe you the page.



The accessible features for editing math is enabled in any WIRIS editor
instance. For example, visit www.wiris.com/demo/editor.  You will need the
AT enabled to test the experience. It works fine with Narrator, Jaws, NVDA
and failed with ChromeVox (but seems easy to fix).



If you want to avoid testing with an AT enabled, you can check our demo at
www.wiris.net/editor/demo and check the text under “Accessible text for the
current position”.



The features for accessibility of WIRIS editor can be found at
http://www.wiris.com/en/editor/docs/keyboardonly



I expect this helps!



Dani







*From:* Charles LaPierre [mailto:charlesl@benetech.org
<charlesl@benetech.org>]
*Sent:* lunes, 24 de abril de 2017 21:42
*To:* Daniel Marques
*Subject:* Re: Meeting today



Hello Daniel,

you were going to email us that url on the editor demo?  Not sure if I
missed it.





Thanks

EOM

Charles LaPierre
Technical Lead, DIAGRAM and Born Accessible
E-mail: charlesl@benetech.org
Twitter: @CLaPierreA11Y
Skype: charles_lapierre
Phone: 650-600-3301





On Apr 24, 2017, at 6:35 AM, Daniel Marques <dani@wiris.com> wrote:



Hi Peter,



Do we meet today at 16:00 CEST/7 AM PST ?



Dani

[math-on-web] a11y TF meeting minutes, 2017/04/24

Source: public-mathonwebpages@w3.org Mail Archives • Peter Krautzberger (peter.krautzberger@mathjax.org) • April 25, 2017 • Permalink

Hi everyone,

below are the minutes from the a11y task force meeting this week.

Best,
Peter.

# mathonweb CG -- a11y TF, 2017/04/24

* Daniel: we're using aria alerts for WIRIS
  * => Demo www.wiris.com/demo/editor,
http://www.wiris.com/en/editor/docs/keyboardonly
  * accessible labels for formula and position
  * Volker: navigation by arrow keys?
    * Yes.
    * Volker: skipping subexpressions?
      * a bit more difficult
  * Daniel: discussing with Sina who didn't like the browsing the entire
toolbar to find the input they want
    * wants shortcuts like `frac`
      * Volker: so a bit like LaTeX
    * Volker: Sina is a power problem. Testing with Sina and grad student
gave a better baseline
  * Charles: could you send link to share?
* Peter: it would be nice to create a page with current practices in
editing
  * Desmos, WIRIS , more?

* Daniel: back to math role
  * now feel it's useful, like img but not "... image" but (sometimes)
"...(math)"
  * Volker: still concerned about "math"
    * not general enough for scientific content (e.g., chemistry)
    * e.g., "equation"
  * Daniel: agree need for more general
* Peter: as per last discussion, roledescription seems destined for htat
  * but "...math" might be more vendor-specific, so we could approach them

* Peter: do you feel ready to discuss with ARIA WG?
  * coordinate, ask them what we can provide them with, how we might help
positively shape
  * Daniel: and simply get to know each other
  * ACTION Yes

* Charles: finishing Benetech epub examples
  * sharing with publishers
  * publishers hammering Benetech
   * state legislation, esp texas, expect WCAG II
  * interest in sharing?
    * ACTION: yes please

* Daniel: do we need TF & CG meeting? maybe unify?
  * Peter: we did talk about other topics
  * Volker: main meeting is useful if there's only few people there
    * TF is good because it's small
  * Peter: seems a11y is main focus, like it b/c we get work done
* Volker: maybe theme?
  * Daniel: maybe better agenda, prep
  * Peter: so maybe a11y - role=math (from 2week ago), Volker demos
    * Volker: https://zorkow.github.io/speech-rule-engine/www/

RE: Meeting today

Source: public-mathonwebpages@w3.org Mail Archives • Daniel Marques (dani@wiris.com) • April 25, 2017 • Permalink

Hi Charles,



That’s true I owe you the page.



The accessible features for editing math is enabled in any WIRIS editor
instance. For example, visit www.wiris.com/demo/editor.  You will need the
AT enabled to test the experience. It works fine with Narrator, Jaws, NVDA
and failed with ChromeVox (but seems easy to fix).



If you want to avoid testing with an AT enabled, you can check our demo at
www.wiris.net/editor/demo and check the text under “Accessible text for the
current position”.



The features for accessibility of WIRIS editor can be found at
http://www.wiris.com/en/editor/docs/keyboardonly



I expect this helps!



Dani







*From:* Charles LaPierre [mailto:charlesl@benetech.org
<charlesl@benetech.org>]
*Sent:* lunes, 24 de abril de 2017 21:42
*To:* Daniel Marques
*Subject:* Re: Meeting today



Hello Daniel,

you were going to email us that url on the editor demo?  Not sure if I
missed it.





Thanks

EOM

Charles LaPierre
Technical Lead, DIAGRAM and Born Accessible
E-mail: charlesl@benetech.org
Twitter: @CLaPierreA11Y
Skype: charles_lapierre
Phone: 650-600-3301





On Apr 24, 2017, at 6:35 AM, Daniel Marques <dani@wiris.com> wrote:



Hi Peter,



Do we meet today at 16:00 CEST/7 AM PST ?



Dani

Re: [wbs] response to 'Call for Review: Publishing Working Group Charter'

Source: public-digipub-ig@w3.org Mail Archives • Johnson, Rick (Rick.Johnson@ingramcontent.com) • April 25, 2017 • Permalink

Florian,

After our conversation at lunch, and assuming acceptance of the proposed changes already communicated around the objections raised by Daniel, does the below resolve your remaining objections?

-Rick



Replace in section 3. Deliverables, the first line:
     “More detailed milestones and updated publication schedules are available on the group publication status page”

with the following:

"The requirements, concepts, deliverables, and milestones listed here have been derived from the preliminary considerations of the Digital Publishing Interest Group (see, for example, the PWP-UCR document) as well as the experiences from the EPUB 3.1 Working Group of the IDPF, especially its work on "Browser-friendly Manifestations". One of the first tasks of the Working Group will be to make a thorough review, achieve consensus on, and document the final list, milestones, and the content of the deliverables of the group.  The more detailed list, milestones, and updated publication schedules are available on the <a href="@@@">group publication status page.</a> "



On 4/18/17, 1:30 PM, "Florian Rivoal via WBS Mailer" <sysbot+wbs@w3.org> wrote:

    The following answers have been successfully submitted to 'Call for Review:
    Publishing Working Group Charter' (Advisory Committee) for Vivliostyle Inc.
    by Florian Rivoal.
    
    
    The reviewer's organization suggests changes to this Charter, and only
    supports the proposal if the changes are adopted [Formal Objection].
    
    Additional comments about the proposal:
       Vivliostyle enthusiastically supports the creation of the Publishing
    Working Group, its high level goals and scope, and the general format
    proposed in the charter.
    
    However, we think there is an important flaw in the charter that must be
    addressed first.
    
    Web Publications outlines a vision of convergence between digital
    publications and the web. We absolutely support this vision, and hope to
    contribute to its realization, both by participating in the WG and by
    integrating these technologies in our products. Convergence of digital
    publications and of the web is central to Vivliostyle's mission as a
    company.
    
    However, to our reading, the existing Web Publications documents are a
    manifesto and declaration of intent, not a concrete proposal to address the
    problem.
    
    As such, we believe that (P)WP should be in scope for this working group,
    and that concrete proposals to achieve this goal should be made, and when
    consensual should be taken up as deliverables of this working group.
    
    We are however opposed to listing WP and PWP themselves as a REC track
    deliverable with dated commitments.
    
    If "Web Publications" and "Packaged Web Publications" are meant to stay as
    general documents outlining the vision independently of any concrete
    implementable and testable incarnation, we think it would be much more
    appropriate to publish them as WG Notes.
    
    If, as their proposed inclusion on the REC track suggests, they are meant
    to be concrete technological proposals, we think the inclusion on the REC
    track is premature, as we do not believe there is consensus on, or even a
    general understanding of, what the concrete realization would be.
    
    Our concrete proposal is to:
    
    - List WP and PWP as deliverables as Working Group Notes and continue to
    refine them as vision and requirements documents
    
    - Give the possibility to the group to take on new deliverables that help
    achieve that vision when they are consensual, possibly by including
    something along these lines in the charter (inspired by the CSSWG
    charter):
    
    > The WG may create new modules within its scope to fulfill or support the
    > vision outlined in WP and PWP. If no participant in the group believes a
    > proposed module is out of scope, and the group has consensus to add it,
    > the group may add a new module. If the participants who object sustain 
    > their objection after discussion, a re-charter to clarify the scope may
    be
    > needed.
    
    ~~~
    
    Independently from this objection, we also make the following suggestion
    (but do not oppose the creation of the WG on these grounds even if it was
    rejected):
    
    For the sake of maintainability and timely progress along the REC track, it
    is sometimes desirable to split a large specification into smaller modules
    (or to do the reverse operation). We do not think it is necessary at this
    point to decide whether to split any particular document into smaller
    modules, but it would be good to keep it as a possibility. We therefore
    suggest the addition of the following sentence to the deliverable section.
    
    > Also, to facilitate timely progress on the REC track and for
    > the sake of maintainability, based on consensus in the Working
    > Group, it may split or merge its deliverables.
    
    
    
    The reviewer's organization intends to participate in these groups:
       - Publishing Working Group
    
    The reviewer's organization:
       - intends to review drafts as they are published and send comments.
       - intends to develop experimental implementations and send experience
    reports.
       - intends to develop products based on this work.
       - intends to apply this technology in our operations.
    
    
    Comments about the deliverables:
       Vivliostyle develops Vivliostyle Viewer and Vivliostyle Formatter,
    respecively an interactive UA and a pdf-generating UA, with support for
    pagination and advanced typographic features based on CSS (and (X)HTML,
    SVG, MathML...).
    
    Vivliostyle's product provide an answer to Pagination
      https://www.w3.org/TR/2017/WD-pwp-ucr-20170309/#pagination

    and also intends facilitate Off-lining and Archiving
      https://www.w3.org/TR/2017/WD-pwp-ucr-20170309/#onloffl

      https://www.w3.org/TR/2017/WD-pwp-ucr-20170309/#archiving

    
    We currently support ordinary web content as well as EPUB3 as input
    formats, and intend to support EPUB4 and other (P)WP formats as they
    appear.
    
    
    Answers to this questionnaire can be set and changed at
    https://www.w3.org/2002/09/wbs/33280/publwg/ until 2017-05-14.
    
     Regards,
    
     The Automatic WBS Mailer
    
    
    

Re: [math-on-web] a11y TF meeting minutes, 2017/04/10

Source: public-mathonwebpages@w3.org Mail Archives • Peter Krautzberger (peter.krautzberger@mathjax.org) • April 13, 2017 • Permalink

> I'm not sure if you can call one person a significant group.

Sorry! I should not have muddled your comment with my own thoughts.

The extension to a group is an observation of mine. That is, I've heard
this point of view from more than one a11y expert (and more than one AT
developer).

Best,
Peter.

On Thu, Apr 13, 2017 at 12:25 PM, Volker Sorge <volker.sorge@gmail.com>
wrote:

> I'm not sure if you can call one person a significant group. I'd rather
> say a highly influential personality given that he is the tech lead on one
> of the most used open source screen readers on Windows.
> And yes he hates the idea of "deep labels" but not aria-labels in general.
>
> Having said that, I've also had a chat with the developer of the main
> screen reader on Chromebooks, who had no problems whatsoever with what
> Peter proposes.
>
> Best
> Volker
>
>
>
> On 13 Apr 2017 11:08 am, "Peter Krautzberger" <peter.krautzberger@mathjax.
> org> wrote:
>
> Hi Daniel,
>
> > Volker says that “some people are opposed to aria-labels”. T
>
> IIRC, Volker was referrring to the deep-labels approach. There seems to be
> a significant group in the a11y world (especially among AT developers) that
> argue against the use of aria-labels (in favor the development of semantic
> notation via roles and eventually tags).
>
> > I do not understand the roledescription solution. Could someone
> rephrase it?
>
> This is the spec: https://www.w3.org/TR/wai-aria-1.1/#aria-roledescription
>
> It allows authors to customize the roles representation within AT (if AT
> supports it). Hence my comment that the argument that role="math" might
> be misleading (for STE content) could be addressed by suggesting to use
> role=math + aria-roledescription="physics".
>
> Best,
> Peter.
>
> On Thu, Apr 13, 2017 at 11:18 AM, Daniel Marques <dani@wiris.com> wrote:
>
>> Hi everybody,
>>
>> After reading the minutes, let me comment on some of the subjects.
>>
>> Volker says that “some people are opposed to aria-labels”. This is
>> consistent with the fact that AT reads the text and ignores the
>> aria-labels. It is also connected with the idea that some people don’t like
>> accessible specific content.
>>
>> The role=math has its faults but does some of the job. I guess that it
>> was a compromise reached time ago in order to use the aria-label (which
>> seems to confirm what Volker said). If deprecated, an alternative should be
>> provided. Maybe another role?
>>
>> I do not understand the roledescription solution. Could someone rephrase
>> it?
>>
>> Dani
>>
>> On 12 Apr 2017, at 18:58, Peter Krautzberger <
>> peter.krautzberger@mathjax.org> wrote:
>>
>> Hi everyone,
>>
>> below are the minutes from the a11y task force meeting this week.
>>
>> Best,
>> Peter.
>>
>> # math on web CG -- a11y TF
>>
>> * Updates.
>>   * Peter: continued work on deep labels
>>     * more examples
>>     * more focused on SVG but should
>>     * more recordings by Thursday, expect to confirm the validity
>>     * one problem: tables mathJax svg vs commonthml
>>       * ARIA 1.1 table-related roles should help
>>   * Peter: also got an update from Jason Meryll
>>     * where he described their work
>>     * ACTION: ask Jason to make it public
>>       * then reference on website
>>   * Volker: from last CG meeting: hacked around with speech API
>>     * prosidy support via SSML in speech synthesis API
>>     * several tests
>>     * no SSML support
>>     * though VoiceOer had some specialized markup (see minutes)
>>     * working on next few examples
>> * Peter: role=math
>>   * not much feedback from CG outside of a11y TF - which may have been
>> obvious
>>   * Volker: at w4a a11y hackathon, nobody even knew the role existed
>>   * Peter: fun fact: James Craig mentioned that the role was derived from
>> image role (which makes sense given the time)
>>   * Peter: from MathJax end, we could delay until we get to working on
>> turning deep labels into something for production
>>   * Peter: given Daniel's comments from last TF meeting, maybe the groups
>> recommendation should be to deprecate role=math.
>>   * ACTION: ask CG for a recommendation
>>     * point out that there are features that would help but that
>> role-math serves no purpose
>> * Volker: some people are opposed to aria-labels
>> * Peter: new roles in ARIA 1.1
>>   * e.g., table related roles
>>   * e.g., roledescription
>>     * Kevin: could be used to specify role='Math'
>>       * Peter: right, argument to say that role is no longer necessary
>>         * but also reversely: role='math' with roledescription='physisc'
>> could argue "against" Daniel's concern.
>> * Volker: will post some examples
>>
>>
>>
>
>

Re: [math-on-web] a11y TF meeting minutes, 2017/04/10

Source: public-mathonwebpages@w3.org Mail Archives • Volker Sorge (volker.sorge@gmail.com) • April 13, 2017 • Permalink

I'm not sure if you can call one person a significant group. I'd rather say
a highly influential personality given that he is the tech lead on one of
the most used open source screen readers on Windows.
And yes he hates the idea of "deep labels" but not aria-labels in general.

Having said that, I've also had a chat with the developer of the main
screen reader on Chromebooks, who had no problems whatsoever with what
Peter proposes.

Best
Volker



On 13 Apr 2017 11:08 am, "Peter Krautzberger" <
peter.krautzberger@mathjax.org> wrote:

Hi Daniel,

> Volker says that “some people are opposed to aria-labels”.. T

IIRC, Volker was referrring to the deep-labels approach. There seems to be
a significant group in the a11y world (especially among AT developers) that
argue against the use of aria-labels (in favor the development of semantic
notation via roles and eventually tags).

> I do not understand the roledescription solution. Could someone rephrase
it?

This is the spec: https://www.w3.org/TR/wai-aria-1.1/#aria-roledescription

It allows authors to customize the roles representation within AT (if AT
supports it). Hence my comment that the argument that role="math" might be
misleading (for STE content) could be addressed by suggesting to use
role=math + aria-roledescription="physics".

Best,
Peter.

On Thu, Apr 13, 2017 at 11:18 AM, Daniel Marques <dani@wiris.com> wrote:

> Hi everybody,
>
> After reading the minutes, let me comment on some of the subjects.
>
> Volker says that “some people are opposed to aria-labels”.. This is
> consistent with the fact that AT reads the text and ignores the
> aria-labels. It is also connected with the idea that some people don’t like
> accessible specific content.
>
> The role=math has its faults but does some of the job. I guess that it was
> a compromise reached time ago in order to use the aria-label (which seems
> to confirm what Volker said). If deprecated, an alternative should be
> provided. Maybe another role?
>
> I do not understand the roledescription solution. Could someone rephrase
> it?
>
> Dani
>
> On 12 Apr 2017, at 18:58, Peter Krautzberger <
> peter.krautzberger@mathjax.org> wrote:
>
> Hi everyone,
>
> below are the minutes from the a11y task force meeting this week.
>
> Best,
> Peter.
>
> # math on web CG -- a11y TF
>
> * Updates.
>   * Peter: continued work on deep labels
>     * more examples
>     * more focused on SVG but should
>     * more recordings by Thursday, expect to confirm the validity
>     * one problem: tables mathJax svg vs commonthml
>       * ARIA 1.1 table-related roles should help
>   * Peter: also got an update from Jason Meryll
>     * where he described their work
>     * ACTION: ask Jason to make it public
>       * then reference on website
>   * Volker: from last CG meeting: hacked around with speech API
>     * prosidy support via SSML in speech synthesis API
>     * several tests
>     * no SSML support
>     * though VoiceOer had some specialized markup (see minutes)
>     * working on next few examples
> * Peter: role=math
>   * not much feedback from CG outside of a11y TF - which may have been
> obvious
>   * Volker: at w4a a11y hackathon, nobody even knew the role existed
>   * Peter: fun fact: James Craig mentioned that the role was derived from
> image role (which makes sense given the time)
>   * Peter: from MathJax end, we could delay until we get to working on
> turning deep labels into something for production
>   * Peter: given Daniel's comments from last TF meeting, maybe the groups
> recommendation should be to deprecate role=math.
>   * ACTION: ask CG for a recommendation
>     * point out that there are features that would help but that role-math
> serves no purpose
> * Volker: some people are opposed to aria-labels
> * Peter: new roles in ARIA 1.1
>   * e.g., table related roles
>   * e.g., roledescription
>     * Kevin: could be used to specify role='Math'
>       * Peter: right, argument to say that role is no longer necessary
>         * but also reversely: role='math' with roledescription='physisc'
> could argue "against" Daniel's concern.
> * Volker: will post some examples
>
>
>

Re: [math-on-web] a11y TF meeting minutes, 2017/04/10

Source: public-mathonwebpages@w3.org Mail Archives • Peter Krautzberger (peter.krautzberger@mathjax.org) • April 13, 2017 • Permalink

Hi Daniel,

> Volker says that “some people are opposed to aria-labels”. T

IIRC, Volker was referrring to the deep-labels approach. There seems to be
a significant group in the a11y world (especially among AT developers) that
argue against the use of aria-labels (in favor the development of semantic
notation via roles and eventually tags).

> I do not understand the roledescription solution. Could someone rephrase
it?

This is the spec: https://www.w3.org/TR/wai-aria-1.1/#aria-roledescription

It allows authors to customize the roles representation within AT (if AT
supports it). Hence my comment that the argument that role="math" might be
misleading (for STE content) could be addressed by suggesting to use
role=math + aria-roledescription="physics".

Best,
Peter.

On Thu, Apr 13, 2017 at 11:18 AM, Daniel Marques <dani@wiris.com> wrote:

> Hi everybody,
>
> After reading the minutes, let me comment on some of the subjects.
>
> Volker says that “some people are opposed to aria-labels”. This is
> consistent with the fact that AT reads the text and ignores the
> aria-labels. It is also connected with the idea that some people don’t like
> accessible specific content.
>
> The role=math has its faults but does some of the job. I guess that it was
> a compromise reached time ago in order to use the aria-label (which seems
> to confirm what Volker said). If deprecated, an alternative should be
> provided. Maybe another role?
>
> I do not understand the roledescription solution. Could someone rephrase
> it?
>
> Dani
>
> On 12 Apr 2017, at 18:58, Peter Krautzberger <peter.krautzberger@mathjax.
> org> wrote:
>
> Hi everyone,
>
> below are the minutes from the a11y task force meeting this week.
>
> Best,
> Peter.
>
> # math on web CG -- a11y TF
>
> * Updates.
>   * Peter: continued work on deep labels
>     * more examples
>     * more focused on SVG but should
>     * more recordings by Thursday, expect to confirm the validity
>     * one problem: tables mathJax svg vs commonthml
>       * ARIA 1.1 table-related roles should help
>   * Peter: also got an update from Jason Meryll
>     * where he described their work
>     * ACTION: ask Jason to make it public
>       * then reference on website
>   * Volker: from last CG meeting: hacked around with speech API
>     * prosidy support via SSML in speech synthesis API
>     * several tests
>     * no SSML support
>     * though VoiceOer had some specialized markup (see minutes)
>     * working on next few examples
> * Peter: role=math
>   * not much feedback from CG outside of a11y TF - which may have been
> obvious
>   * Volker: at w4a a11y hackathon, nobody even knew the role existed
>   * Peter: fun fact: James Craig mentioned that the role was derived from
> image role (which makes sense given the time)
>   * Peter: from MathJax end, we could delay until we get to working on
> turning deep labels into something for production
>   * Peter: given Daniel's comments from last TF meeting, maybe the groups
> recommendation should be to deprecate role=math.
>   * ACTION: ask CG for a recommendation
>     * point out that there are features that would help but that role-math
> serves no purpose
> * Volker: some people are opposed to aria-labels
> * Peter: new roles in ARIA 1.1
>   * e.g., table related roles
>   * e.g., roledescription
>     * Kevin: could be used to specify role='Math'
>       * Peter: right, argument to say that role is no longer necessary
>         * but also reversely: role='math' with roledescription='physisc'
> could argue "against" Daniel's concern.
> * Volker: will post some examples
>
>
>

Re: [math-on-web] a11y TF meeting minutes, 2017/04/10

Source: public-mathonwebpages@w3.org Mail Archives • Kevin Cheung (KEVINCHEUNG@CUNET.CARLETON.CA) • April 13, 2017 • Permalink

As far as I understood roledescription, it is an extra piece of information that can be provided to qualify a specified role.  For example, if the role is “image" with roledescription “math", that means the image is actually math.

Regarding creating an alternative role for mathematics, I wonder what it could be.  To some people, a math expression looks like a picture.  So an image role seems fitting.  But to some people, a math expression is a syntax tree in disguise.  Would a role called tree be appropriate?  That sounds a bit complicated.

Kevin.

On Apr 13, 2017, at 5:18 AM, Daniel Marques <dani@wiris.com<mailto:dani@wiris.com>> wrote:

Hi everybody,

After reading the minutes, let me comment on some of the subjects.

Volker says that “some people are opposed to aria-labels”. This is consistent with the fact that AT reads the text and ignores the aria-labels. It is also connected with the idea that some people don’t like accessible specific content.

The role=math has its faults but does some of the job. I guess that it was a compromise reached time ago in order to use the aria-label (which seems to confirm what Volker said). If deprecated, an alternative should be provided. Maybe another role?

I do not understand the roledescription solution. Could someone rephrase it?

Dani

On 12 Apr 2017, at 18:58, Peter Krautzberger <peter.krautzberger@mathjax.org<mailto:peter.krautzberger@mathjax.org>> wrote:

Hi everyone,

below are the minutes from the a11y task force meeting this week.

Best,
Peter.

# math on web CG -- a11y TF

* Updates.
  * Peter: continued work on deep labels
    * more examples
    * more focused on SVG but should
    * more recordings by Thursday, expect to confirm the validity
    * one problem: tables mathJax svg vs commonthml
      * ARIA 1.1 table-related roles should help
  * Peter: also got an update from Jason Meryll
    * where he described their work
    * ACTION: ask Jason to make it public
      * then reference on website
  * Volker: from last CG meeting: hacked around with speech API
    * prosidy support via SSML in speech synthesis API
    * several tests
    * no SSML support
    * though VoiceOer had some specialized markup (see minutes)
    * working on next few examples
* Peter: role=math
  * not much feedback from CG outside of a11y TF - which may have been obvious
  * Volker: at w4a a11y hackathon, nobody even knew the role existed
  * Peter: fun fact: James Craig mentioned that the role was derived from image role (which makes sense given the time)
  * Peter: from MathJax end, we could delay until we get to working on turning deep labels into something for production
  * Peter: given Daniel's comments from last TF meeting, maybe the groups recommendation should be to deprecate role=math.
  * ACTION: ask CG for a recommendation
    * point out that there are features that would help but that role-math serves no purpose
* Volker: some people are opposed to aria-labels
* Peter: new roles in ARIA 1.1
  * e.g., table related roles
  * e.g., roledescription
    * Kevin: could be used to specify role='Math'
      * Peter: right, argument to say that role is no longer necessary
        * but also reversely: role='math' with roledescription='physisc' could argue "against" Daniel's concern.
* Volker: will post some examples


Re: [math-on-web] a11y TF meeting minutes, 2017/04/10

Source: public-mathonwebpages@w3.org Mail Archives • Daniel Marques (dani@wiris.com) • April 13, 2017 • Permalink

Hi everybody,

After reading the minutes, let me comment on some of the subjects.

Volker says that “some people are opposed to aria-labels”. This is consistent with the fact that AT reads the text and ignores the aria-labels. It is also connected with the idea that some people don’t like accessible specific content. 

The role=math has its faults but does some of the job. I guess that it was a compromise reached time ago in order to use the aria-label (which seems to confirm what Volker said). If deprecated, an alternative should be provided. Maybe another role?

I do not understand the roledescription solution. Could someone rephrase it?

Dani 

> On 12 Apr 2017, at 18:58, Peter Krautzberger <peter.krautzberger@mathjax.org> wrote:
> 
> Hi everyone,
> 
> below are the minutes from the a11y task force meeting this week.
> 
> Best,
> Peter.
> 
> # math on web CG -- a11y TF 
> 
> * Updates.
>   * Peter: continued work on deep labels 
>     * more examples
>     * more focused on SVG but should 
>     * more recordings by Thursday, expect to confirm the validity
>     * one problem: tables mathJax svg vs commonthml
>       * ARIA 1.1 table-related roles should help
>   * Peter: also got an update from Jason Meryll
>     * where he described their work
>     * ACTION: ask Jason to make it public
>       * then reference on website
>   * Volker: from last CG meeting: hacked around with speech API
>     * prosidy support via SSML in speech synthesis API 
>     * several tests 
>     * no SSML support 
>     * though VoiceOer had some specialized markup (see minutes)
>     * working on next few examples 
> * Peter: role=math
>   * not much feedback from CG outside of a11y TF - which may have been obvious
>   * Volker: at w4a a11y hackathon, nobody even knew the role existed 
>   * Peter: fun fact: James Craig mentioned that the role was derived from image role (which makes sense given the time)
>   * Peter: from MathJax end, we could delay until we get to working on turning deep labels into something for production
>   * Peter: given Daniel's comments from last TF meeting, maybe the groups recommendation should be to deprecate role=math.
>   * ACTION: ask CG for a recommendation
>     * point out that there are features that would help but that role-math serves no purpose
> * Volker: some people are opposed to aria-labels
> * Peter: new roles in ARIA 1.1 
>   * e.g., table related roles 
>   * e.g., roledescription
>     * Kevin: could be used to specify role='Math'
>       * Peter: right, argument to say that role is no longer necessary
>         * but also reversely: role='math' with roledescription='physisc' could argue "against" Daniel's concern. 
> * Volker: will post some examples 

[math-on-web] CANCEL meeting 2017-04-13

Source: public-mathonwebpages@w3.org Mail Archives • Peter Krautzberger (peter.krautzberger@mathjax.org) • April 12, 2017 • Permalink

Hi everyone,

Given the large number of regrets (including both Daniel and me), we should
cancel the meeting this week.

See you in two weeks!
Peter.

[math-on-web] a11y TF meeting minutes, 2017/04/10

Source: public-mathonwebpages@w3.org Mail Archives • Peter Krautzberger (peter.krautzberger@mathjax.org) • April 12, 2017 • Permalink

Hi everyone,

below are the minutes from the a11y task force meeting this week.

Best,
Peter.

# math on web CG -- a11y TF

* Updates.
  * Peter: continued work on deep labels
    * more examples
    * more focused on SVG but should
    * more recordings by Thursday, expect to confirm the validity
    * one problem: tables mathJax svg vs commonthml
      * ARIA 1.1 table-related roles should help
  * Peter: also got an update from Jason Meryll
    * where he described their work
    * ACTION: ask Jason to make it public
      * then reference on website
  * Volker: from last CG meeting: hacked around with speech API
    * prosidy support via SSML in speech synthesis API
    * several tests
    * no SSML support
    * though VoiceOer had some specialized markup (see minutes)
    * working on next few examples
* Peter: role=math
  * not much feedback from CG outside of a11y TF - which may have been
obvious
  * Volker: at w4a a11y hackathon, nobody even knew the role existed
  * Peter: fun fact: James Craig mentioned that the role was derived from
image role (which makes sense given the time)
  * Peter: from MathJax end, we could delay until we get to working on
turning deep labels into something for production
  * Peter: given Daniel's comments from last TF meeting, maybe the groups
recommendation should be to deprecate role=math.
  * ACTION: ask CG for a recommendation
    * point out that there are features that would help but that role-math
serves no purpose
* Volker: some people are opposed to aria-labels
* Peter: new roles in ARIA 1.1
  * e.g., table related roles
  * e.g., roledescription
    * Kevin: could be used to specify role='Math'
      * Peter: right, argument to say that role is no longer necessary
        * but also reversely: role='math' with roledescription='physisc'
could argue "against" Daniel's concern.
* Volker: will post some examples

Feeds

Planet MathML features:

If you own a blog with a focus on MathML, and want to be added or removed from this aggregator, please get in touch with Bert Bos at bert@w3.org.

(feed)This page as an Atom feed

A mechanical calculation machine (with an added W3C logo)

Bert Bos, math activity lead
Copyright © 2008–2015 W3C®

Powered by Planet