Re: Revise group description?

And here’s where I have to disagree Arved…

Now that the W3C is working with the IDPF and there’s an official Digital Publishing Interest Group, I don’t think you can accurately say that "Our major end user community here is not professional publishing experts.” In fact, going forward, I think any additional participation in the PPL group will be representative of the professional publishing expert community.

That said, for developers that don’t work specifically in publishing content, yes, maybe .1% may not have heard of, or care very much about print publishing production. :)

However, for publishers, and the publishing production services companies that serve publishers, the numbers are MUCH higher, and the W3C has just started the conversation with this group of people.

I think we’re all aware that the term “publisher" is not just limited to people who produce some kind of content for sale these days. Publishers are people who deal with content across the board. This means that in addition to the Publishing industry, enterprise corporations have hundreds of people dedicated to publishing content – marketing, regulatory submissions, service information, production documentation, and a whole list of other content products that are far more than reports. In an enterprise corporation, service information, product information, and parts lists alone equal content products that are worth a significant bit of money to the overall enterprise.

But back to how we wound up where we are with XSL-FO…

The publishing industry has already been down the path of investigating XSL-FO (they went there about 10 years ago) and found the available product offerings too complicated and often insufficient to the sophisticated layouts required. This is why much has been made over the capabilities of Indesign and Quark. Not because publishers paid big money for software licenses, but because these products go the companies much closer to the level of quality and functional output they were looking for than the other options available. Further, the learning curve to educate existing staff was not so steep as to become unaffordable in terms of time necessary for retraining as well as financial outlay.

I’ve noticed at various “publishing people meet standards community and developer people" meetings that developers and standards community people keep asking people in the publishing industry “why don’t you just go hire developers instead of trying to turn your people into something they are not?” I can tell you why… Salaries. Developers make much more money than publishing house production people do. You might be able to hire a developer for the average publishing production’s person salary in Detroit, MI, but this will not fly in California or New York. Therefore, publishers lean toward solutions that their people understand and can work with without incurring a huge time and training investment compared to what it takes to make automated lights out publishing engines go.

Enterprise publishing has also been down the path of investigating XSL-FO, too (going as far back as the first implementations of XSL-FO publishing engines). Pre-DITA (what’s the BC equivalent of pre-DITA? PD?)  the enterprise publishing community came to the conclusion that XSL-FO engines would not only be insufficient to their publishing tasks (say in the instance of doing a pharmaceutical regulatory submission), but also required a whole level of developer expertise that would be a continuing and ongoing expense moving forward. This was back in the days when the level of markup technology maturity was still at: you must build a DTD/Schema that meets your company needs. Or adopt an existing standard like Docbook, and then change it to meet your needs.”

The combination of the existing XSL-FO options, the need to decide upon, and the customize and maintain a schema, and the fact that existing publishing staff would have to be completely re-educated to become developers was deemed to be too expensive and time consuming, not to mention distracting from the core business at hand – the reason for publishing in the first place. Most enterprise content outside of some industries such as defense contracting and manufacturing still does not start life in any kind of solution remotely related to standards-based markup technologies. Companies have been piloting standards based markup technology based systems for 20 years, but simpler solutions – usually involving Microsoft Word, and content strategy processes that would give most content strategists nightmares continue to prevail. Why? Because they consistently get the bottom line done in a way that the staff they have on hand can understand.

Recently, this has changed a bit because of more and more enterprises adopting DITA and related content strategies, architectures, and technologies that go with DITA. Even here, though, the people who work with DITA – the writers, the information architects - the people who are making content products with DITA - are NOT the people who are responsible for keeping the DITA technologies up and going for the organization. It’s only the DITA system administrators and developers who know what’s going on under the hood. And this is actually one place where XSL-FO has been successful – by nature of the fact that the DITA Open Toolkit, a reference implementation system that was never supposed to be an actual enterprise level production system took off like gangbusters because it was the only game in town, and because it was easier to get people to compromise on their printed output, which was not incredibly complicated to begin with, than it was to get funds to build a purpose built system that met all of their requirements.

This does not mean that DITA OTK developers who work for enterprise corporations do not pull their hair out over getting the DITA OTK to do new and different tricks, though. But the number of people who are expected to extract some new requirement out of the DITA OTK is minimal compared to the number of people who are supposed to produce DITA content, throw it into a repository, let someone else assemble it into a product, and let yet another person worry about how it goes from the repository to a screen or PDF. In fact, you could probably argue that XSL-FO’s most successful implementation to date is the DITA OTK. A reference implementation that was never supposed to be a production system…

Why do I know where these industries have been? Because I was there, too. I worked for the big pharmaceutical house during the days when XSL was continually misspelled “XLS” and when  XSL-FO engines were considered too expensive, yet too slow and requiring too much of a learning curve to bring even a minimal staff up to speed.

I also worked as a consultant where my customers were enterprise publishing organizations who were far more interested in getting their content out the door to their resellers, partners, and customers, and who had already significantly invested in non-XSL-FO technologies that were working for them. Better yet, they’d invested so much in these non-XSL-FO technologies, that they actually had reached a point with the vendors where they could say “here are the requirements we want you to build to, and no, we’re not interested in XSL-FO.” I mean, if you’re a big enough company that can turn the entire R&D team of a software company toward meeting your specific requirements, and that company has already rule out XSL-FO as the basis for one of their formatting engine, would you really tell them, rip out what you’ve done and replace it with XSL-FO? Especially if you already looked at XSL-FO with your software vendor and chose to go in another direction 10 years ago?

Finally, I’ve worked in publishing. I’ve worked in scholarly publishing, educational publishing, and trade and professional publishing (all that other stuff – the pharma, the consulting, that was in and between publishing gigs). Publishing requirements differ a bit from vertical to vertical within publishing, but one thing remains the same – the fact that most publishing production people do not start out as developers (I certainly didn’t. I learned by osmosis. The music school I attended was on the same campus as the engineering school!). Most of these people have no interest in becoming developers. (With the exception of those music school people who went to school on the engineering campus. I once worked on a team of 6 developers. 3 of us had gone to said music school.) Most people just want to get their content project out the door and move onto the next project, because that’s what they’re paid to do. This is what they understand.

In fact, I did an Arbortext lights out FOSI engine based publishing project with a small team of people at and educational publishing house and the production editorial team was appalled at how much time it took for them to manipulate files and run Arbortext. Why? Because by that point in time, the publishing production people who worked for the publishing house were more like project managers that outsourced the actual publishing production activities to publishing production services vendors. Actually getting their hands dirty with publishing production tasks reduced their level of productivity in context of their jobs as project managers, and meant they could only focus on one project at a time instead of the 5-6 projects on their plate. This particular production team didn’t care how the content made it from the computer to the printed page so long as they weren’t involved in the actual task. We got through the project, the books were published, and boy was that team relieved to take the workflow right back to their outsource vendors, no matter how much money was saved.

And what do the publishing production services companies work with? (I’m particularly up on this stuff now, since I moved from the publishing house to the publishing production services side of the equation.) Publishing production technologies and workflows depend very much on the production services provider and are considered the “special sauce” that differentiate the vendors in the market. Most publishing production services companies have some level of automation and scripting involved in their production workflow. Some of them are working with in-house Indesign Server production workflow systems to get paged output (which makes sense if you are working for actual publishers). Others continue to work with TeX and LaTeX built into proprietary in-house workflow systems (which makes sense if you’re working specifically with scholarly publishers). I am not aware of a single independent large publishing production service provider that has built their internal tools around XSL-FO and XSL-FO engines, though.

So from my perspective and experience, I can tell you – it’s not that XSL-FO suffers from lack of advertising or marketing. It’s that the level of complexity required to make an XSL-FO system go in Publishing “the Industry” or the 80% of enterprise publishing that is not concept, task, or reference based, that made other solutions more viable. Why the solutions are more viable depends on context, but much of it comes from the people issue involved. People who are not interested in becoming developers, the expense of well trained developers, the level of sophistication in the technology compared to what can be done with technologies that were originally designed for highly designed content formats (marketing, advertising, magazines, scholarly, 4 color layout intensive text books).

And now… After all of this time… The publishing industry AND enterprise content publishing, and marketing, advertising, sales, service information, in addition to other types of publishing, are no longer even focusing purely on the concept of the page or printed output at all. This means that there will continue to be niche areas for page-based publishing, but that the days of successfully advertising XSL-FO as a viable option to the needs of the larger community are not in front of us. The larger community looked. A while back. And then they looked at the other parameters and decision making factors involved, and went in the direction that made the most sense at the time based on tools, support, people issues, and relationships with existing tool vendors. This isn’t to say that there’s no place for XSL-FO going forward, clearly, the DITA community and other people have decided that XSL-FO fit the bill. But I think we’re long past the point where any advertising campaign will inspire people to go look at XSL-FO again.

Apologies for the blog length response. Clearly you touched something approach a 20 year old nerve…

In fact, does anyone on the list mind if I reuse any of my diatribe for a blog post? I won’t mention anyone in the group by name…

And now I’m off to try to reconstruct the memory of what it was I had originally sat down at the computer to do this afternoon.

Happy New Year everyone!

-Jean

From: Arved Sandstrom <asandstrom2@eastlink.ca<mailto:asandstrom2@eastlink.ca>>
Date: Saturday, December 28, 2013 at 12:49 PM
To: "public-ppl@w3.org<mailto:public-ppl@w3.org>" <public-ppl@w3.org<mailto:public-ppl@w3.org>>
Subject: Re: Revise group description?
Resent-From: <public-ppl@w3.org<mailto:public-ppl@w3.org>>
Resent-Date: Saturday, December 28, 2013 at 12:49 PM

On 12/28/2013 11:06 AM, Tony Graham wrote:
On Tue, December 17, 2013 6:19 pm, Jean Kaplansky wrote:
I know that most of the activity in this group has been around XSL-FO, but
I think we might get more interest if we just say:

“For people interested in page layout technologies…” rather than
explicitly saying XSL-FO.

I have a hunch that this may be chasing any but the most hardcore XSL-FO
enthusiasts away. We already know that there are a lot of people
experimenting with CSS for print, for example. Also while most people
think of eBooks as being reflowable, there’s a huge demand for fixed
layout pages in eBooks in trade and educational titles. We should try to
get some of these people interested in the group.

Just my $.02.

-Jean K.

From: Dave Pawson <dave.pawson@gmail.com<mailto:dave.pawson@gmail.com><mailto:dave.pawson@gmail.com>>
...
An alternative:
the Print & Page Layout Community Group is  here to discuss XSL-FO,
requirements or other aspects of XML in print.

The success of the XSL-FO as a technology shows there's a
strong interest in development and  implementation. The
Print and Page Layout Community Group is intended as a place to
build a  community of XSL-FO users and  raise the
visibility of this  technology
I don't think that it is viable for this CG to be only about XSL-FO.  I,
personally, would much rather that this CG was neutral ground rather than
just the last bastion of XSL-FO.  It is, of course, the last bastion of
XSL-FO just because there is no other, but if that shouldn't be our sole
purpose.
[ SNIP ]
Fine post, very useful to me in summarizing issues. I am not intimately
involved in the print and publishing field: for me it's an incidental
albeit fairly frequent requirement to produce nicely-formatted stuff on
paper. By incidental I mean simply that the printing requirement is
secondary to systems that I am engaged to develop; but that does not
diminish its importance. After all, people do love their reports. :-)

Name of the game out in the field, apart from publishing-oriented
systems that I know very little about, developers muckle onto a library
that works (like iText) or use a built-in for a BI system. A handful of
folks use TeX/LateX or XSL-FO. If a client happens to have Quark or
InDesign for some reason you try to use that, not because you want to,
but the client paid big $$$ for the software.

What I am saying is that like 0.1 percent of all developers on the
planet have ever heard of most of the technologies and products we are
talking about here. But a whole whack of developers will be asked at
some point to produce pretty reports: they will not be using a
purpose-built high-end publishing app to do it. A successful and
pervasive approach to print and publishing focuses - IMHO - on libraries
and APIs for the most popular programming languages. Our major end user
community here is not professional publishing experts.

XSL-FO still has a chance for the needs of the larger community, I
think. But it's not being well advertised.

Arved