[TYPO3-doc] About DocBook 5 Customization
François Suter
fsu-lists at cobweb.ch
Mon Dec 13 22:05:35 CET 2010
Hi,
>> - Dividing big manuals in small parts what can be combined together (e.g. the
>> TSref manual is very big)
>
> Lately I've used dbautosplit, a Perl script which splits a DocBook document into smaller
> chunks. It is not perfect, but it does its job pretty well.
> If you have migrated your legacy documents into DocBook 5 this could be
> useful.
Good to know. It could be useful indeed.
>> - Much linking between manuals and to URIs outside (the problem is often broken
>> links because of changed URIs)
>
> Yes, linking can be a pain. Are you talking about internal or external links?
From what I understand from DocBook (which is not yet much) internal
links are not really problematic. Our issue is really with external
links, i.e. linking across manuals, but also outside links pointing to
manuals. This is in large part due to the current transformation to
HTML, how speaking URLs are managed by TYPO3 and - more generally - the
structure of the community site typo3.org.
The real headache we're having right now is that most of the time when a
manual is generated the numbering of the chapters changes. This means
that existing links are broken (plus the fact that the full URLs also
contain the version of the manual, which doesn't help). So the problem
is not strictly related to DocBook, but we're hoping that DocBook can
help. In particular I was thinking that if we give "speaking" IDs to
sections, these can be used when creating our speaking URLs rather than
(potentially changing) numbers.
As an example, here's a link to the "doc_core_tsconfig" manual:
http://typo3.org/documentation/document-library/core-documentation/doc_core_tsconfig/4.3.2/view/1/6/
The problem with the version number must be handled on the TYPO3 side,
but it would be much better if we could use more explicit keywords than
"/1/6". This is probably something that needs to be solved on the TYPO3
side too, but with information extracted from the DocBook files.
BTW I'm wondering how a full manual rendered to HTML would fit into the
structure of typo3.org. Currently the manuals are cut into HTML "pages"
that correspond to chapters. These "pages" are stored in a database
table (AFAIK, I'm unsure about this part) and are served as content
inside the site's template when requested. I'm not sure how this would
be achieved after the DocBook migration. Could we have a rendering that
splits the HTML into several files that would be equivalent to the
"virtual pages" that we have now?
(I don't know if this is really clear for you :-/ )
> Use the xml:lang attribute. This is available in all elements.
Ah yes, quite obvious :-) I was looking for some "lang" tag...
> 1. Which block elements do you need (especially sectX vs. section)?
> 2. Should content models can be simplified?
> 3. Which inline elements do you need?
> 4. Can para be simplified?
I'm currently preparing a sample DocBook document based on our current
template, so that we have a first example which should normally contain
most of what we should need. I'm also using the FLOW3 (TYPO3's next
generation PHP framework) documentation as a reference, as it seems
quite clean and well structured.
> I prefer this style:
>
> <para>Some text...</para>
> <figure>...</figure>
> <para>Another text<filename>x</filename></para>
> <example>...</example>
>
> I'm not sure if this is important for you, but if you don't restrict it, writers
> will use it. This leads to inconsistencies which should be avoided.
Interesting. This makes sense IMO.
Cheers
--
Francois Suter
Cobweb Development Sarl - http://www.cobweb.ch
More information about the TYPO3-project-documentation
mailing list