Re: [docbook-apps] Of interest,

[Robert Winslow Dalpe <rwdalpe@gmail.com>]

Thanks for sharing this article, Dave; it was a very interesting read.
And the post to which it linked near the end is also intriguing:
<http://www.infogridpacific.com/blog/igp-blog-20130210-avoid-xml-first-like-the-plague.html>.

Whenever I read articles or posts about using [X]HTML as a content
source, a part of me recoils. It strikes me as going down the road to
an un-reusable, presentation-over-content model. But as I author
content and work with other content producers, I keep pondering a
conflict between what I see as two primary needs of publishers. It has
made me re-think my position somewhat. The second article I linked by
Richard Pipe gets at the crux:

    1. I desire that my media be consumable by my customers in the
format of their choosing. Else they may not be able to consume it.
    2. Even more importantly, however, I desire that my media behave
and look appealingly or appropriately to the context in which my
customers will be consuming. Else they may not be satisfied by or even
bother with consuming it.

Just to qualify, it's from my own anecdotal experience that the second
need is more important. I think that, as it stands today, customers
are more likely to adapt to a different format which has a superior
experience than to consume content in their preferred format with an
inferior experience.

And while on the surface these two needs don't seem to be conflicting,
I think they do conflict regarding implementation details. The first
requirement conveys a need for quick or easy pivoting to new format
types. That implies to me some agnostic, unchanging source which can
be transformed as new formats come about. The second requirement,
however, derives from the fact that publishing, editing, and authoring
are arts at their core. The art targets a specific media format and
must be able to exploit that format to be successful. As Pipe puts it
in his comments on the linked article, "Ultimately to represent the
creations of authors and editors the requirement is to put any content
structure anywhere and in anything."

I think we can all agree that what works in print format may not seem
natural or applicable to web formats, but I believe it goes beyond
that. It seems to me to be: "We must handle one format differently
from another. But also in arbitrary cases within a format it is true
that we must improvise to exploit the format." E.g. "Our print
admonitions are all consistent. Our web admonitions are not only
different from our print admonitions, but also this specific web
admonition should be different from the rest." Or some other
requirement such inserting hyphenation or spacing as described in the
original article linked by Dave.

So, how does this affect us today? What does it mean for
presentation-agnostic sources that presentation accommodations are
important end goals? I think it means:

    1. The barrier between authoring and visualization must be as low
as possible. Creators must be able to get between what they have, the
source, to what they want, the finished product, as quickly and
repeatedly as possible.

I think a lot of the reason we see so much hype over HTML-based
workflows is because of this. Almost nothing is easier than editing a
file, popping it open in your web browser, and then clicking "Print"
(or running 1 command through Prince) to get a PDF. That's fast
iteration with great tooling support. I think it's worth noting,
though, that this is a boon from the tools surrounding the format
rather than the format itself.

    2. The source must be directly amenable to as many presentation
details as possible.

This is where I think HTML+CSS really shines. It supports arbitrary
structural elements and mature presentation details via CSS. That
gives a lot of power over native presentation details. Moreover, HTML
benefits from XML tooling for transformations which can support
presentation details. I think most publishers are fine with simple,
easily understood transformations. The kind that move a structural
element from one place to another, add some spacing, generate variable
content, or chunk a document. There's just less cognitive overhead in
understanding what's happening there. And with HTML, transformations
can be (relatively) simple because they don't have to introduce or
change much. They can just move pieces around and let structure+CSS do
the work.

    3. The source format should be as ubiquitous as possible.

Network effects are powerful, and HTML has an enormous edge in that
space. Everyone is familiar with it, and so many formats either use
HTML as their base, or enjoy tooling for direct transformation from
HTML. On top of that, you can take presentation-ridden HTML and strip
it down to reasonably presentation-agnostic markup. This requires a
bit of thoughtfulness to how you write your HTML, but it's almost the
best of all worlds. You can write presentation-specific content for
the myriad formats that support it today, and then strip it all down
and rebuild if you ever need to. As opposed to starting with something
stripped down and needing to build it up every time.

I think it's fair to say that if HTML is not the source in which we
should write content, it should be the primary target to which content
is transformed. Then all further transformation and presentation is
done on top of HTML. That's how I've been doing my publishing, and it
works well. I enjoy DocBook's vocabulary and tooling. But I do wonder
if everything wouldn't be simpler if I authored in HTML directly, or a
plaintext format which processed to HTML directly for further
modification.

Winslow


On Mon, Feb 20, 2017 at 11:27 AM, Dave Pawson <dave.pawson@gmail.com> wrote:
>
> Book publishing.
>
> https://www.xml.com/articles/2017/02/20/beyond-xml-making-books-html/
>
> regards
>
> --
> Dave Pawson
> XSLT XSL-FO FAQ.
> Docbook FAQ.
> http://www.dpawson.co.uk
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: docbook-apps-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: docbook-apps-help@lists.oasis-open.org
>