[TYPO3-doc] DocBook: customizing the schema

François Suter fsu-lists at cobweb.ch
Thu Jun 16 17:19:06 CEST 2011


Hi Tom,

Thanks for your detailed posting.

> For example, I've started with the FLOW3 manual and experienced some things
> that I would consider as disadvantageous:
>
>    * Block elements in<para>s,
>
>    * bridgeheads, floating titles without any child structures.
>
> Both issues make XSLT processing harder to some extend, especially when it
> comes to customizing the DocBook XSL stylesheets. As such, I banned them from
> the RELAX NG schema. Both issues can be solved through some XSLT magic, by the
> way. You can find the modified version in our docu SVN[1].

Sounds good.

> Furthermore, we've discussed sect1 vs. section which we solved already: we
> decided for section.

Exactly.

> Some open questions still persist:
>
> 1. How "restrictive" want we to be?
>[snip]
>
> 2. What should we do with semantical similar elements?
> [snip]

Answering those 2 questions together: I think we should not be too 
restrictive. OTOH I think it's worth banning as many tags as possible to 
make editor's lives easier and the editing process less prone to 
mistakes. DocBook sometimes goes into a lot of details, which I don't 
think is necessary. Your example with all the "gui*" tags is a perfect 
one. With the sample manual I tried to use most of the tags that I think 
we would need, so I would take it as a basis for restrictions. Of 
course, this is open for discussion as I may well have missed some 
useful tag.

> 3. Do we want to allow "foreign" DocBook vocabulary (like SVG or MathML)?

I don't know. I wouldn't expect math formulas to be necessary. SVG could 
be nice I guess, although our need for charts is pretty limited. Most of 
our pictures are screenshots. I suppose it's still possible to point to 
an SVG file, right?

> 4. Should we allow annotations?
>
>     Annotations are pretty new in DocBook. They are introduced in version 5.
>     With annotation you can attach additional information to an element.
>     In PDF it is suppressed, but in online formats it can show an icon
>     after the annotated element. When you click the icon, it will show
>     a kind of popup with the annotation.
>     I would recommend to remove them for the time being. If they are
>     really needed, we can add them later.

I read quickly about the topic and I agree with you: let's leave them 
aside for now, we can always add them later on.

> 5. What table model do we use?
>
>     If I remember correctly, we favored the HTML table model instead of CALS.
>     Is this still right?

Yes.

> 6. Consistent Linking?
>
>     DocBook 5 allows XLinks. They are present in almost all elements which
>     means you do not need necessarily a special<link>  element. In theory,
>     you can turn every element into a link using the xlink:href attribute.
>     This adds more expressive power to our markup, but it's maybe harder to
>     understand.
>     Should we use explicitly<link>  for our external links and disallow
>     XLinks? Again, consistency vs. flexibility.

I would say that links are indeed easier to understand (and especially 
to keep an overview of). In the sample reference manual I also used xref 
tags. Is that related to your question?

> I know, the above questions are very detailed. However, we should decide these
> questions _now_ as they influence the way we structure our TYPO3 manuals in
> the near future. They will also influence the design.

Sure.

> Remember, a good schema is only the basis. However, it doesn't necessarily
> mean all your documents are perfectly good. A writer still can use the "wrong"
> element,  disobey any style guide recommendations, or use an unfortunate
> structure. DocBook doesn't prevent you from doing this, nor the schema
> customization.
> But a good schema allows a writer to get help what is allowed and what is not.
> A kind of "guided editing", a "contract". Not more, not less.

I understand and agree :-)

Cheers

-- 

Francois Suter
Cobweb Development Sarl - http://www.cobweb.ch


More information about the TYPO3-project-documentation mailing list