Standard versus proprietary

[ptc-1908075]

FWIW: At this point, I think standard versus proprietary is a red herring. Things are just not that clear-cut.
FOSI is both a standard and proprietary. Same for XSL-FO. APP is proprietary, except for the JavaScript part. Adobe PostScript and PDF are proprietary languages that are de facto standards.
Standards are great, but I think what matters most is stuff like cheaper,faster,easier,more productive, better quality, etc.
Suzanne Napoleonwww.FOSIexpert.com"WYSIWYG is last-century technology!"

[LynnHales]

Another ‘misdirected’ email.



Lynn

[GregoryMackenzi]

Back in the day one of the arguments for switching to SGML was that we were trading content in a proprietary software for ascii thus making the content portable and reusable at a fragment level. I would observe that effective re-use of fragment content seldom occurs. At that time Adobe Pagemaker was doing just fine for production of Technical Manuals and we didn’t have to buy a licence to print to PDF since that feature is built into the software. That printing wasn’t built into Arbortext Editor by default, and that print composer and FOSI were now required in order to get a similar product out the door to the customer was, well, shocking. There’s a certain amount of irony in that all we appear to have really done is to change masters so to speak. And, after all this time my observation is that customers still want their document output as the proprietary Adobe PDF files. I really have to consider whether or not the documentation, and its presentation of content, couldn’t be just as well done, if not better, in Adobe InDesign with some kind of content management system. Certainly I’d have much more control over the format and appearance of S1000D documents for example which are produced at the DM level and aggregated into a larger publication.

[LynnHales]

I have been involved with TMs for over 45 years, either as a user (who questioned the ancestry of the people who gave the TMs to us), as an acquisition manager, authoring support for a contractor (one of those of questionable ancestry), and TM standards developer (trying to get better data to the user).

The biggest issue I have had with SGML or XML has been the lack of viable styling tools. FOSI was a good idea and is, to me, still a very potent formatting tool.



There are formatting tools available, but implementation has always been proprietary.

PDF has come a long way since it was first introduced, but as you say, we are really under the control of Adobe.



IF and the is a BIG word, users could agree on how to display data that DOES NOT LOOK LIKE A PIECE OF PAPER we’d go a long way to moving away from PDF and page based scenarios. To me the problem is that most users do not want to change what they started out with. As I said in a previous post in this thread, the “That’s the way we’ve always done it.” syndrome still reigns.



Lynn

[JasonBuss]

And Lynn hits the crux of the challenge right there. Vendors are insistent that everyone needs to be moving to electronic-only delivery, but there’s still so many of us who are (begrudgingly) still supporting “pages”.

Even if your end delivery is PDF, people still want to know how many pages are in this document? What page does this topic/task begin on? What pages can I find this keyword from the index on (shudder)? FOSI in general, and Print Composer in particular, is REALLY good at doing this, that’s why a lot of people have hung on to it so long, and why there’s such gnashing of teeth about sunsetting it now.

Even in industries where the vast majority of customers want their technical data electronically, there’s always that fistful that want paper, and they want it easy to use. Some industries (looking at you, FAA) are required by regulation to supply a paper copy if asked. I’ve tried to explain that when 75% of your stylesheet development and maintenance is being spent to support 10-20% of your customers, it’s really starting to feel like a non-value activity. But that’s a culture shift that some folks are just not ready to swallow yet.

While I am lamenting the challenge of trying to produce paper-based content with toolsets that are being put out to pasture, I am (deep down) hopeful that the lack of availability and support for those kinds of tools may break loose that final resistance to moving away from page-based technical manuals.

That being said, I do realize there are some military customers who may never let it go ☹

-Jason

[GregoryMackenzi]

When given a choice between HTML delivery and PDF customers invariably choose a PDF “Book” with its traditional page layout presentation. That’s why I suggest ATA or S1000D Data Modules could just as easily be prepared and presented via InDesign, or even “gasp” MSWord, for example with a lot less fuss. IETPs/IETMs are critiqued for their lack of bookishness, basically books are something we’ve been using culturally for quite a while, they work, and one might argue book presentation still has validity and is even preferred. You can print it, take it with you, and paper never needs batteries.

[ClayHelberg]

Hi Greg—

I have a couple of responses to this:


1) Re: whether print or online is better, there are advantages to both of course. You do a good job of outlining the advantages of print, but online has the advantages of being searchable and “surfable” (containing hyperlinks to related information, to let you instantly see the list of steps in a referenced subprocedure). Also, in many circumstances, it is more portable. You can load an entire 747’s worth of maintenance manuals on a laptop (or access it remotely on a tablet or even a phone in a pinch), but you’d better have a cart handy if you want to bring the printed version out on the tarmac.

2) Re: authoring systems, there are many advantages to structured authoring beyond just the (often unfulfilled) promise of content reuse. They include ease of translation (where a lot of companies get their real monetary ROI), separation of formatting from content, and enforcement of authoring standards (through DTD/Schema and additional systems like Schematron for enforcing business rules). With desktop publishing systems like InDesign or Word, my experience is that authors can’t resist spending a lot of extra time tweaking formatting and (inadvertently) introducing inconsistencies in content, which a copy editor then has to spend time undoing when the full document base is assembled. Structured authoring removes that temptation, so authors can focus on producing good, consistent content and leave the formatting to the stylesheet.

--Clay

[GregoryMackenzi]

Hi Clay,

Oh yeah, I hear you on the roomful of books! A dvd of pubs definitely saves space. I recognize that Word definitely presents configuration problems and rigorous enforcement of its use vis-à-vis styles and ad-hoc formatting are always an issue even with the most disciplined users. I don’t think the outline view is used enough!

Greg

[ChrisWestern]

And besides the Perl, DOM, XPath, XSLT, XInclude, SVG, Parsing, Unicode, Unipair etc. parts.

In Reply to Suzanne Napoleon:

APP is proprietary, except for the JavaScript part.