On 26/03/2014 2:14 PM, Christopher R. Maden wrote:
Although I don’t get a vote, I completely agree with Glenn that DITA
integration into FOP is completely inappropriate.
Thanks for taking the time to comment. I appreciate the input - voting or not.
I also challenge Ron’s assertion that DITA users are the biggest users
of FOP; DocBook is way up there too, along with an uncountable number of
other document types.


You certainly have reason to challenge my assertion!
I could not determine the number of downloads of FOP from Apache last week but FOP was downloaded 344 times last week as part of DITA-OT.

There could be other ways to measure "biggest user of FOP" but I could not find any way to determine these.
Is there some data from FOP about usage?

DITA-OT does DocBook as well but I am not sure how many DITA-OT users are still working with DocBook.



If the DITA team wants to turn ownership over to the Apache Foundation,

I think that this would be the result and the current license is Apache V2.

that’s one thing; there are several projects that coöperate with FOP
(and some on which FOP depends), but they are not and should not be
*part* of FOP.
Part of the issue that I think needs to be addressed is the difficulty in using DITA-OT caused by missing FOP functionality. These are not getting fixed or even addressed for a number of reasons that relate to communication and probably resources where users of DITA-OT need FOP support but the people supporting DITA-OT don't have a connection to the FOP team and the end-user with the financial resources does not see the connection between FOP and DITA-OT. They just get told that DITA-OT can't do X because FOP can't support it - end of story.

The lack of FOP consultants in the DITA-OT community also makes it difficult to get customization/configuration of FOP done. This makes it difficult to get nice looking output or dynamic creation of documentation on demand.

“Tightening the link between FOP and DITA” is a bad thing.  Separation
of concerns makes semantic markup work and makes Free/Open Source
Software work.  DITA (and other good XML vocabularies) are all about
describing information in a presentation-independent kind of way, and
then applying one or more presentation specifications to produce output.
  The presentation layer should be separate.  While many (most?) DITA
users depend on FOP, not all do,[*] and there are certainly many FOP
users who do not need to be saddled with DITA (or DocBook, or CALS, or
TEI, or ...).

I would not suggest that the code be integrated but it would be nice to have a single group that can say. "if you want to support X in DITA-OT for PDF output, then you to add Y to DITA-OT and Z to FOP and these can be done through the release of FOP version zzz and version yyy of DITA-OT.

One alternative would be to fork FOP and do the extensions of FOP in the DITA-OT group but that is not anyone's preference


There are alternatives to processing DITA. FOP is not used in DITA-OT for HTML or OOxml or rtf output.

I am not sure how many of the alternative DITA processors have forked the Apache FOP base and integrated it into the programs. It certainly would give one a head start on building a proprietary DITA to PDF process and would likely have a lot of bits and pieces that one could use for other XML output.

I think that there is a lot of expertise in the XMLGraphics group that could make a big difference in the usefulness and functionality of DITA-OT just by commenting on the internal processes and reviewing the enhancement plans.



~Chris

[*] My entire experience with DITA has been around an MS-Word-centric
publication system, going into and out of Office Open XML, with no XSL
in sight.


--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Reply via email to