OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Aggregated Editing

Dear colleagues

I have been following the discussions on aggregated editing, and particularly the issues raised at the last meeting. (I'm sorry that my time zone makes attending meetings problematic.)

Some years ago, I spent a lot of time using a hypertext authoring tool called HDK, and it's successor, XDK. It was built as an add-on to Word. Its architecture may provide some ideas for how aggregated DITA editing might work. 

The HDK project file stored project settings, as well as the "ingredient list" of the project. The ingredient list was a represented as a TOC-like tree. HDK was topic based, but the topics were stored and edited in Word. A project could be set up with one topic per Word document, or multiple topics per Word document. There could be one or many Word documents in the project. The sequence of topics in Word documents was irrelevant to the output, and irrelevant to the order of topics in the TOC. Included in the topic's metadata (stored in the ingredient list in the project file) was the file name of the Word document in which the topic lived, and the unique topic identifier (effectively a Word bookmark name) within that document. A hard page break served as a topic divider; hard page breaks could not be used for any other purpose. A topic could be split into two through an HDK dialog box, which would result in a new page break and topic title being inserted.

In other words, this approach allowed HDK to be a topic-based authoring tool within an aggregated editing environment.

Translating that approach to a DITA environment, we would start with the ditamap being the aggregating plan. In an aggregated editing program yet to be developed (let's called it "Aggie"), when a ditamap was opened, the topics would be opened in sequence and dynamically merged into a linear document stream. Aggie would place some sort of topic divider token between topics. 

When the user made a change to one topic in the document stream, the topic would be marked by Aggie as "dirty". When the user saved the "document", Aggie would save the changes back to the topic file name. When the ditamap was closed, 
Aggie would then delete the temporary document stream. If a topic was split into two, or a new topic was added, this would be facilitated by the insertion of a new topic break token, topic metadata, and a prompt for a file name. 

Any other operations within the Aggie editing environment, such as cross-topic cross-referencing, conreffing and reltable changes, would be handled in pretty much the same way as any normal DITA editor. This is because the linear document stream is only an illusion. You could still have other users using a different topic-based editor to edit the same topics. Different Aggie users could possibly use different ditamaps (or even conditions in the map) to work with a different aggregation of topics.

As far as I can see, no changes to DITA would be required for Aggie to be created. Aggie might use ditabase for its temporary linear document stream, but that would be an application-specific format anyway. Aggie could probably use the ditamap as its "project" file, although if something fancy was required, such as the topics displayed in the aggregated form in a different sequence to the ditamap, then a specialised ditamap might be needed. Aggregated editing would be entirely an authoring workflow choice, and not an architectural decision.

Hope this is useful.

Tony Self

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]