You could ditch template wars by insisting everyone in your organisation uses an industry standard. Try DocBook, an SGML standard for authoring technical documenation. I've used this for a number of years, knowing the information I'm producing will be processable in years to come. It's scaleable to huge numbers of large documents, so with that covered, you can go back to arguing about which fonts to use for command names;)
The whole challenge of single-sourcing isn't in which technologies to use, but the integration of these technologies, the process by which content is produced and the interaction between content (knowledge) producers.
For example, at my last company we wrote software products. Document engineers would typically take one of the (almost) finished products and start writing documentation from scratch. Technical information that was already stored in programs, on wikis, in configuration files, etc.. was duplicated in the official documentation. The results were mixed- although the documentation engineers were very professional and diligent, all sorts of inaccuracies crept in.
How do you produce documentation without any duplication? That's a real challenge. XML is part of the answer because you can automatically transform XML information into a publishable format. But no company has all their technical information in one place, in one format. Scripting languages and literate programming are also part of the solution. But the challenge is in getting the collaboration between different people from different departments to work.. Changing the organizational culture from the lazy habit of copy-and-pasting information to the stop-and-think habits required for single-sourcing.
Such a zero copy-and-paste organization is really hard to achieve, well done to the author for addressing this issue.
This section of the memo was, for me, the most interesting:-
3. Extensions do not support modularity.
As new extensions are introduced, they are released separately under their own names and distributed generally. Each one may go through several revisions as separate modules. At some point, they are then folded into base Java, tying base Java's version to the versions of dozens of smaller yet distinct functionalities. These functionalities are then restricted to a draconian backward-compatibility rule since once folded in, they are no longer selectable modules. Examples include modules that used to be called Swing, RTI, IDL, JSSE and JAAS. These are all good things that should be part of Java. Our concern is that these are not separable modules which can evolve as requirements change.
The Java system for evolving the interface (deprecation) does not serve production software very well. Once the interface disappears, the product just breaks. If the Java base were simpler and the more advanced features (those most likely to be deprecated) were delivered as versioned modules, it would be possible for a commercial product to retain it's older modules on the system and survive a large number of Java upgrades.
Production quality programs written in Java, like TogetherJ, indicate a specific Java version which must be installed before the program is run. If another program is installed, requiring a higher Java version, the user may be forced to decide which program stays and which goes away.
Alternatively, the other Java version could be installed to a different base directory but this requires considerable sophistication on the part of the user, complicates administration and violates the ARC big rule that common software must be shared.
In earlier Java releases there were useful APIs that weren't available in the core, such as XML/XSLT, JNDI, Swing, etc.. but for application developers like me, it was straight-forward enough to distribute these extensions with applications that needed them. Sun's policy of bloating the core with all these Java extensions is actually harmful to Java. For example, Sun's official explanation for putting logging facilities that were inferior to Apache's log4j was that there
was a JDK 1.4 Merlin release deadline to meet.
Same goes for the stunted XML API's in JDK 1.4. Why can't these extensions grow, evolve and mature outside the Java core? As long as they're easy enough to distribute, do they need to be part of one big release?
What the Sun engineers are complaining about is that a change in one of what could be hundreds of extensions breaks the entire platform. To try to prevent this, Sun have imposed 'draconian binary-compatibility rules' which are a sure way of prohibiting refactoring and major improvements, bottom line: Java bloats and innovation effectively stops.
Either Java needs to use it's own extension mechanism more consistently, or to create one that is more flexible/usable and more open to third-party code. How many times have you needed a particular version of xerces, xalan or log4j in the classpath? (or found out your customer has a different version that the one you built with, and this is the cause of that subtle and evasive bug)
It's not just the Solaris performance/memory aspects of Java that are a problem, it's the very way that the technology is distributed and evolves. I've had a lot of fun/success with Java and want it to continue getting better. Congratulations to the insightful engineers behind this memo.
Slashdot Mirror
You could ditch template wars by insisting everyone in your organisation uses an industry standard. Try DocBook, an SGML standard for authoring technical documenation. I've used this for a number of years, knowing the information I'm producing will be processable in years to come. It's scaleable to huge numbers of large documents, so with that covered, you can go back to arguing about which fonts to use for command names ;)
The whole challenge of single-sourcing isn't in which technologies to use, but the integration of these technologies, the process by which content is produced and the interaction between content (knowledge) producers.
For example, at my last company we wrote software products. Document engineers would typically take one of the (almost) finished products and start writing documentation from scratch. Technical information that was already stored in programs, on wikis, in configuration files, etc.. was duplicated in the official documentation. The results were mixed- although the documentation engineers were very professional and diligent, all sorts of inaccuracies crept in.
How do you produce documentation without any duplication? That's a real challenge. XML is part of the answer because you can automatically transform XML information into a publishable format. But no company has all their technical information in one place, in one format. Scripting languages and literate programming are also part of the solution. But the challenge is in getting the collaboration between different people from different departments to work.. Changing the organizational culture from the lazy habit of copy-and-pasting information to the stop-and-think habits required for single-sourcing.
Such a zero copy-and-paste organization is really hard to achieve, well done to the author for addressing this issue.
This section of the memo was, for me, the most interesting:-
In earlier Java releases there were useful APIs that weren't available in the core, such as XML/XSLT, JNDI, Swing, etc.. but for application developers like me, it was straight-forward enough to distribute these extensions with applications that needed them. Sun's policy of bloating the core with all these Java extensions is actually harmful to Java. For example, Sun's official explanation for putting logging facilities that were inferior to Apache's log4j was that there was a JDK 1.4 Merlin release deadline to meet. Same goes for the stunted XML API's in JDK 1.4. Why can't these extensions grow, evolve and mature outside the Java core? As long as they're easy enough to distribute, do they need to be part of one big release?
What the Sun engineers are complaining about is that a change in one of what could be hundreds of extensions breaks the entire platform. To try to prevent this, Sun have imposed 'draconian binary-compatibility rules' which are a sure way of prohibiting refactoring and major improvements, bottom line: Java bloats and innovation effectively stops.
Either Java needs to use it's own extension mechanism more consistently, or to create one that is more flexible/usable and more open to third-party code. How many times have you needed a particular version of xerces, xalan or log4j in the classpath? (or found out your customer has a different version that the one you built with, and this is the cause of that subtle and evasive bug)
It's not just the Solaris performance/memory aspects of Java that are a problem, it's the very way that the technology is distributed and evolves. I've had a lot of fun/success with Java and want it to continue getting better. Congratulations to the insightful engineers behind this memo.