Re: Revise group description?

Jean, happy NY to you too (and others). And may I say that if all 
"diatribes", expositions and verbal sallies are as well reasoned and as 
heartfelt (I'd say passionate, but that is a seriously over-used word in 
IT) as what you and Tony wrote just now, it would be a continuing 
delight to participate in technical discussions.

I think we'll continue to disagree on some points, which is cool - we 
approach the matter from different backgrounds. I'll make a few 
rejoinders here, simply to clarify my thinking.

1) You use the phrase "far more than reports". We could possibly have a 
clashing definition of "report": although I eschew routine references to 
Wikipedia, my idea of "report" is basically 
http://en.wikipedia.org/wiki/Report. In other words, documents that are 
as sophisticated and element-rich as anything else out there. A fair bit 
of what I do as a software consultant for government and corporations 
involves reporting.

2) And although this is anecdotal - my own experience and what I have 
heard from colleagues over the years - I think there are at least two 
major communities to be considered here. Organisations whose raison 
d'etre is publishing, and organisations who have publishing requirements 
but their existence is not contingent upon it. I have always worked with 
the latter. By organisation I don't mean just company, it can be 
department or section.

A lot of publishing - a very large percentage in my opinion - is 
undertaken by small groups (one to <5 people). It's not uncommon for a 
government department or company with several thousand people to have 
dozens of 1-2 person groups who have a publishing task. And they are 
directed by different people, funded through different channels, and 
there is no uniformity as to technology. So you may have dozens or 
hundreds of people in an enterprise who publish content, but really 
there are very many independent teams.

Small groups like this don't have the sophistication, background or cash 
to invest in, or master, everything we are talking about here. We have 
mentioned a slow rate of XSL-FO adoption: guess what, the majority of 
developers don't know XSLT at all, let alone know how to use it well. 
The majority of developers have never read the XML spec for that matter, 
which is foundational.

3) My last paras agree and disagree with several of your points. A fair 
bit of publishing that I replace as a consultant is Excel reports (not 
so much MS Word :-)). People hate the Excel/Word approach, but the 
automated approach requires developers and apparently costs more money. 
Ostensible fail.

Are developers more expensive than front-line UI button pushers? I doubt 
it. But I'm a developer, I'm biased. :-)

4) Totally with you on DITA, I've mentioned it before, I use the 
technology. I like it. Hard to sell sometimes; ironically 
people-intensive systems often win out.

As a developer I think that the adoption problems with XSL-FO _are_ 
perception, and in fact bad advertising. You've got like a few tens of 
millions of coders on the planet, and a lot of them get HTML and 
JavaScript and CSS. Master all that, and you could master XSL-FO.

Arved

On 12/28/2013 03:24 PM, Jean Kaplansky wrote:
> 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>
>         <mailto:dave.pawson@gmail.com%3E>>
>
>     ...
>
>         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
>
>