# RE: Minimal Viable Publication (was Re: Active lobbying: Math)

From: Bill Kasdorf <bkasdorf@apexcovantage.com>
Date: Fri, 21 Aug 2015 16:03:35 +0000
To: Leonard Rosenthol <lrosenth@adobe.com>, Deborah Kaplan <dkaplan@safaribooksonline.com>, Ivan Herman <ivan@w3.org>
CC: W3C Digital Publishing IG <public-digipub-ig@w3.org>, Peter Krautzberger <peter.krautzberger@mathjax.org>, Karen Myers <karen@w3.org>, Ralph Swick <swick@csail.mit.edu>
FYI, George Kerscher has been working for months to develop and refine a "Baseline for Accessibility" that while addressing the accessibility issue more broadly than just for math, is a closely related concept to the "Minimal Viable Publication" concept.

I think this is absolutely the right way to be looking at these issues. Too often we get hung up on edge cases. Let's get it "mainly working." Then we can move on to work on what else doesn't yet work as well as we'd like. For a spec as complex as MathML and a need as complex as math markup and rendering, insistence on perfection is deadly, and looking at the issue as a binary--either it all works, or we think "it doesn't work"--is our biggest enemy.

-----Original Message-----
Sent: Friday, August 21, 2015 11:25 AM
To: Deborah Kaplan; Ivan Herman
Cc: W3C Digital Publishing IG; Peter Krautzberger; Karen Myers; Ralph Swick
Subject: Minimal Viable Publication (was Re: Active lobbying: Math)

Deborah - your post is quite interesting to me in pointing out that while we are all striving for the “best possible publication”, the practical matter is that we can’t have that today.  Instead, publishers have to look for “lowest common denominator” or what might also be seen as a "Minimal Viable Publication” (MVP).  Would you agree?

If so, what would you consider that MVP?  What features and/or requirements have to be present in an RS and/or file format?

Thanks,
Leonard

On 8/21/15, 11:02 AM, "Deborah Kaplan" <dkaplan@safaribooksonline.com> wrote:

>On Fri, 21 Aug 2015, Ivan Herman wrote:
>
>> But I guess that is history. Peter can tell us more what kind of (clearly unsuccessful) lobbying happened in this area and what MathJax feels is the best way forward. And we have to think about how to make bridges between the Publishing and the Browser people, e.g., by bringing together some higher level than what we represent in this group; after all we are all geeks and not suits:-). Let us not give up yet...
>
>"Not giving up" is why I exasperates so many people. :D
>
>A core issue I think we should focus on when it comes to lobbying, not just for MathML/MathJax, but for everything else, is to remember that browsers are not not necessarily the core limitation for a lot of publishing. For all that browser limitations  are very big deal, they still have more features than many of the dedicated reading systems. For one thing, they can run polyfills!
>
>And ultimately, no matter how rich a digital publication 90% of the available reading systems can support, many publishers will have to produce a single publication that does not break the remaining 10%.
>
>Lobbying toward the dedicated reading systems is one solution. I know a lot of that work has already happened.
>
>Maybe the actual solution, though, is to come up with some kind of workarounds to enable single digital publication support in reading systems with a variety of technological limitations. In digital publishing, perhaps more than in other industries, this is always going to be a chokepoint. Perhaps the real thing we need to be advocating for is coming up with a standard, non hacky solution to support changes moving forward.
>
>HTML conditionals, like the zombified revivification is NOSCRIPT.  IF / ELSE blocks which get read as comments in non-supporting versions, and which can contain solutions for moving forward.
>
>(Though polyfills are difficult in digital publishing for reasons other than simply reader support;   platforms which provide reading systems for publications they don't control are going to be tetchy about JavaScript; that problem isn't going away anytime soon, either.)
>
>Deborah Kaplan
>

Received on Friday, 21 August 2015 16:04:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:36:08 UTC