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: [email protected]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
