Re: Revise group description?

You make many flat statements without any sources to back it up Jean.
I do hope readers take your 'facts' as personal opinion.

regards DaveP


On 28 December 2013 19:24, Jean Kaplansky <Jean.Kaplansky@aptaracorp.com> 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>
> Date: Saturday, December 28, 2013 at 12:49 PM
> To: "public-ppl@w3.org" <public-ppl@w3.org>
> Subject: Re: Revise group description?
> Resent-From: <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>>
>
> ...
>
> 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
>
>



-- 
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.
http://www.dpawson.co.uk

Received on Sunday, 29 December 2013 08:27:44 UTC