The move to custom XML

Gerard Beekmans gerard at linuxfromscratch.org
Tue May 20 14:24:12 PDT 2003


On May 20, 2003 02:21 pm, Matthias Benkmann wrote:
> About the chapter 6 text being mostly identical to chapter 5. I would keep
> that redundancy. I thought about using ids in the chapter 5 instructions
> and backreferencing them in the chapter 6 part. I also thought about
> declaring common text fragments before the 2 sections and reference them.
> I don't like it. It makes it harder to read and write. Considering that

That's how it's done now yes. For instance a package description is stored in 
appendixa/bash-cont.xml (bash's contents) and it's included with an entity 
three times: in chapter 5, 6 and appendix A itself.

If this were to be made monolithic, we'd have to update the contents section 
three times and it is easy to forget one of them. I rather update one single 
file and have it included dynamically wherever needed, for example by using 
<xinclude> (right now entities are used but that's to be considered a bad 
thing from the past that we'lll be erradicating mostly, though entities do 
have some uses elsewhere in the book).

> the 2 texts are so close to each other in the same file, there's no
> maintenance argument to be made for avoiding the redundancy. Keeping them
> in sync with manual copy'n'paste in an editor is so trivial and quick. I
> think any kind of mechanism to avoid the redunancy would just introduce
> complexity and make things harder to read without being any real help.

Yes it'll be a bit harder to read, you wouldn't see the actual dependencies 
but instead an <xinclude> tag to include the packages dependency file. But 
like I said above, it's worth it to me not having to remember every single 
instance of duplication so the book will remain in sync.


-- 
Gerard Beekmans
http://linuxfromscratch.org

/* Linux Consultant --- OSDN / DevChannel *
 * Technical Writer --- CheapBytes        */

/* If Linux doesn't have the solution, you have the wrong problem */

-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message



More information about the lfs-dev mailing list