Proposal for Implementing a Docbook Editor

[satya komaragiri]

Hello Chris,

On Mon, Mar 23, 2009 at 11:37 AM, Christopher Curran <ccurran at redhat.com> wrote:
> I say good luck to you, Satya.
>
> No, seriously, I hope you are successful.

Thanks a lot :)
>
> Just some tips I've gleaned from similar projects that have failed:
> * Don't extend the spec. It is the downfall of most XML editor/interpreter
> projects that the developers involved decide to add substantial amounts of
> metadata or additional tags into the XML.

Yes, we'll keep that in mind. All we are doing is transforming the XML
to HTML using XSLT and the HTML format will just be suiting our needs
so we can use it in the editor. The output XML will be standard
without any unwanted changes.

> * Avoid directional and positional data. If you include lots of positional
> data (like openoffice does) other interpreters will struggle and it will
> undermine a core tenet of DocBook, single sourcing. The easiest way to avoid
> this is to use a html/CSS approach. We all know tables are bad because too
> much of the positional data is hard coded at the wrong level. When display
> data is stored separately your code is more portable and easier to single
> source.

That is the agenda. We do plan to go the HTML/CSS way (Beacon already
does that). Tables will be included only if the content writer
himself/herself wants the Docbook XML to contain a table.

> * Use existing tools. I don't know how many times I have seen someone
> rewrite an XML parser or similar but it is quite a few. I like your approach
> of using XLTS, stick with it :)

Thanks, we might need to modify the XSLs a bit to suit our
requirements but we won't be re-inventing the wheels.

>
> Good luck,
> Chris
>

Regards,
Satya