On 09/07/2010 19:21, Sergei Gorelkin wrote:
I'd suggest the following:
1) XML stays :-)
2) The fpdoc is modified in a way that, after parsing the initial XML,
every text node
within <short> or <descr> elements is additionally parsed with another
parser.
3) The "another parser" does its job, placing its results into a DOM
fragment.
4) The original text node is replaced with the resulting subtree.
5) Choose the new format so it does not use '<' and '&' extensively,
because these will have to be escaped.
This way, it will be possible to mix 'old' and 'new' syntax within a
single document to any extent, and we won't need to touch the backends
at all.
I don't quite see why we need to change the storage format? Most of the
discussion is about issues applying to editing the content.
Especially since a new content format together with the need of reading
old files too, will always leead to the need of supporting 2 file
formats => that IMHO is the worst solution.
You can have an editor that displays and edits the content in any format
you like and validates it at the same time. But it saves it in the
current format after all.
so you edit: "[b]key[/b] < 1"
and the editor saves: "<b>key</b> < 1"
You need the translator anyway, for dealing with old files, so you may
rather put the translator into the editor.
that allows to offer different editors for different likes of different
people.
\bkey\B < 1
*key* < 1
true wysiwyg
....
Martin
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
