I guess we should at some point discuss the whole SGML infrastructure in
CDE.
http://tldp.org/HOWTO/DocBook-Demystification-HOWTO/sgml.html
This link provides a decent 'demystification' of docbook and where it is
going.
http://tldp.org/HOWTO/DocBook-Demystification-HOWTO/
XML is the current markup format, and explains why the openjade (onsgmls
et. al.) tools haven't been updated since 2005. We are essentially
replacing one ancient tool, with a slightly less ancient tool.
From the page:
http://tldp.org/HOWTO/DocBook-Demystification-HOWTO/sgml.html
=-=
"13.3. Why SGML DocBook is dead
The DSSSL toolchain is, as far as new development goes, effectively
dead. The XSLT toolchain has reached production status in mid-2002; a
working version shipped in Red Hat 7.3. It's where DocBook developers
are putting almost all of their effort.
The reason for the change to XML was threefold. First, SGML turned out
to be too complicated to use; then, DSSSL turned out to be too
complicated to live with; then, significant parts of the DSSSL toolchain
turned out to be weak and irredeemably messy.
Relative to SGML, XML has a reduced feature set that is sufficient for
almost all purposes but much easier to understand and build parsers for.
SGML-processing tools (such as validating parsers) have to carry around
support for a lot of features that DocBook and other text markup systems
never actually used. Removing these features made XML simpler and
XML-processing tools faster.
The language used to describe SGML DTDs is sufficiently spiky and
forbidding that composing SGML DTDs was something of a black art. XML
DTDs, on the other hand, can be described in a dialect of XML itself;
there does not need to be a separate DTD language. An XML description of
an XML DTD is called a schema; the term DTD itself will probably pass
out of use as the standards for schemas firm up.
But mostly the DSSSL toolchain is dead because DSSSL itself, the SGML
stylesheet description language in that toolchain, proved just too
arcane for most human beings, and made stylesheets too difficult to
write and modify. (It was a dialect of Scheme. Your humble editor, a
LISP-head from way back, shakes his head in sad bemusement that this
should drive people away.)
XML fans like to sum up all these changes with "XML: tastes great, less
filling."
=-=
:)
So - is anyone on this list familiar with docbook XML want to take up
the task of upgrading our documentation format and generation to
something from this decade?
Short term, using a new onsgmls is probably the way to go, but long
term, it seems clear we need to update to a proper, modern docbook XML.
-jon
On 07/31/2018 12:53 PM, Jon Trulson wrote:
On 07/30/2018 10:29 PM, Matthew R. Trower wrote:
Chase via cdesktopenv-devel <cdesktopenv-devel@lists.sourceforge.net>
writes:
The reason I chose opensp instead of sp is simply because when I tried
installing sp on Lubuntu, it gave me an error saying "Package sp has
no installation candidate", although it is in the debian repos, so I
don't know whats happening with that. I also picked it due to looking
at the *bsd and solaris repos, and most seem to have opensp, but not
sp itself.
On July 30, 2018 5:53 PM, Jon Trulson <j...@radscan.com> wrote:
Well, I'd like to hear from Chase as to whether that is actually the
case on Debian.
As I mentioned before, nsgmls exists on Ubuntu 16.04 after installing
the "sp" package.
At least on illumos/OpenSolaris, opensp contains onsgmls and nsgmls.
The latter is a link to the former. I don't think the opensp package
itself contains these links; I think it is a distribution "extra".
Debian 9 contains opensp, but not sp. There is no symlink from onsgmls
to nsgmls. I can't comment on BSD at this time.
I checked on ubuntu 16.04, it has both "sp" and "opensp". Installing
"opensp" does provide the onsgmls program. nsgmls comes from the "sp"
package, and is not a symlink to onsgmls.
I have confirmed that FreeBSD also has opensp in its ports collection --
I'm not sure about OpenBSD. So it does seem like opensp is the way to go.
I'm not really familiar with these programs, but it seems to me that
OpenSP is the continuation of SP (any expert is welcome to correct me).
As such, I'd say we should default to using that (and onsgmls), rather
than old SP. If people want/need to use old SP, they can always
override it in host.def.
That's the impression I got too, however if you go to the opensp
(OpenJade) SF page, it isn't updated very often, and there seems to be
no interaction with the developers.
https://sourceforge.net/projects/openjade/
There are 71 open tickets reports with no responses by any of the
developers that I could see in my skimming around. It does not seem
very actively developed, but there does not seem to be any alternative.
And of course, if we know about types of systems where that's necessary,
it could go into their system cf files.
Some links about SP and OpenSP
SP: http://www.jclark.com/sp/howtoget.htm
OpenSP: http://openjade.sourceforge.net/doc/index.htm
Version histories, which seem indicative of a transition.
SP: http://openjade.sourceforge.net/doc/new.htm
OpenSP: http://openjade.sourceforge.net/doc/NEWS
OpenJade in general
http://openjade.sourceforge.net/
I guess we should stick to onsgmls for now.
Chase: Did it actually work well? The help system, man pages, and
dtinfo stuff worked/looked ok?
--
Jon Trulson
"Fire all weapons and open a hailing frequency for my victory yodle."
- Zapp Brannigan
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
