[TYPO3-doc] DocBook: Miscellaneous

[Thomas Schraitle]

Hi Sebastian,

Wednesday 27 April 2011
> 
> > Maybe I've misunderstood something, but I'm not sure if this is useful.
> > To make it fly you need some important prerequisites:
> > 
> > - No XML source can be shared between other books
> 
> Hm; I'd use an approach as outlined in
> http://www.sagehill.net/docbookxsl/ModularDoc.html#XIncludesCatalogs
> we have a custom catalog in our build process anyway, and all "common"
> texts (like introductionary texts, a description of TYPO3, ...) could be
> included using this technique.

Ok, XML catalogs are always a good idea. The xmllint tool supports it really 
well. 

 
> I don't see yet that other texts like Images, chapters, ... should be
> shared in between books. Rather, a crosslink should be done in this case.

I don't know the TYPO3 documentation well enough to have a good overview. Yes, 
I agree, a link should be enough.

 
> > - Linking between books become difficult, even impossible
> 
> Using olinks, that would not be a problem. Would it? :-)

Well, I've outlined my problems with olinks in the other mail. :)

 
> I imagine the following: All documents (books, guides, ...) *need to be
> aware of their place in the output hierarchy*, i.e. they need to know
> where in the output they will be located. For this output hierarchy, we
> can automatically generate a Sitemap file (used for olinks), and by
> that, you can link to other books.

Hmn, I don't want to assimilate this thread and turn it against olinks. :) 
Again, the details are in the other mail. If possible, I would use just a 
simple link and point to a _stable_ HTML file.

 
> > I'm not a Git expert so maybe there is some Git magic which makes it
> > possible to mix and match different repositories. However, I'm not aware
> > of any.
> 
> That's also possible, using "Git Submodules" -- however it has some
> smaller drawbacks, as you can only point to specific revisions inside a
> submodule. But I think we would only need this as convenience for
> editors (so they would not have to check out 100 separate git
> repositories); and the rendering pipeline would not need this.

Ahh, ok. Brilliant! :) Thanks for the explanation.


Bye,
  Tom