Joe Malin wrote:

> Well, I *finally* finished the new book for our next software
> release, so I can justifiably turn my attention to getting myself
> into structured docs.

Ah, some time to play... ;-)

> I am not going to go with DITA just yet. My plan is to convert my 
> existing unstructured docs to structure first, and then start the
> next round of docs in DITA. So, my first decision is what EDD to use.
> Should I develop an EDD myself from scratch, or start with the
> DocBook EDD? My only hesitation in using the DocBook EDD is that it
> will have a lot of elements that I don't want to use.

In my opinion, the last sentence hints that you already know the answer 
to your question. My long-standing belief is that if you try to 
structure your data in accordance with what tools you currently have at 
hand, you're focusing on the wrong issue. Your documents have an 
inherent structure, and you should respect and support it. There is a 
cost to every single XPath that you don't use, so something like DocBook 
can be a very expensive approach. If you cut it down, you'll often find 
that you're left with the right elements, but the names may not be what 
you'd choose yourself. Also, DocBook is very loosely structured, so you 
may want to tighten up the models - by the time you go through all of 
this, you may as well have just done the analysis yourself and started 
with the pre-existing (but implied) structure of your documents.

Although there may be good reasons for going to DITA, I've never had 
reason to do so, as I feel that the benefits gained from standardisation 
would quickly dry up as soon as you started customising. I'd be inclined 
to convert to DITA as a final process if you really had a need to mix 
and match modules, but I would probably choose a more descriptive syntax 
for data creation and management.

> Any advice, particularly from those who have gone the same route,
> would be much appreciated.

Fifteen years of SGML and XML consulting and publishing and pretty much 
as much involvement with FrameMaker for me. I'm also involved with the 
emerging field of XML Governance, partially because my company has seen 
so many substandard approaches taken to structuring data and the current 
inability to manage XML-based projects effectively.

> As you probably know, I have many years experience in software 
> development, so developing my own EDD is not an issue.

You're perfectly positioned to start this off right.


Marcus Carr                      email:  mcarr at
Allette Systems (Australia)      www:
"Everything should be made as simple as possible, but not simpler."
        - Einstein

Reply via email to