On Mon, Oct 18, 2004 at 01:39:08PM +0200, Andre Poenitz wrote:
> On Sun, Oct 17, 2004 at 10:34:28PM +0200, Andreas Vox wrote:
> > Hi LyXers!
> >
> > I would like to propose an architecture for a C++ wrapper on eXpat or
> > libxml for parsing LyX XML. Disclaimer: I'm not a C++ programmer,
> > so don't expect correct syntax or correct STL names.
>
> I don't think I agree with the idea.
>
> LyX's C++ wrapper for XML can be fairly close to LyX's internal
> structure. There's no need to invent another tree architecture in
> parallel to the existing inset hierarchy, so a naural solution woud be
> something similar to that 'MetaInset' I proposed earlier. This is
> sufficient to store data and attributes in a way that makes it more
> uniform acessible from the outside than the current inset hierarchy with
> individual 'hand coded' attributes, yet plugs into the inset hierarchy
> and thus can be handled in the 'customary LyX way'.
I agree with Andr� here. If you look to the lyx structure you will see
that the export code for lyx is quite simple. There are some improvements to
be made here, as Lars DTD shows but the code there is quite robust, and I
don't see any need for additional complexity.
Because then the SAX/DOM that you propose would need to mimic the lyx
internal strucutre.
> Without further clarification I don't see any real advantage. It looks
> like you are looking for a solution for the wrong problem. LyX knows how
> to create and handle tree-structured data. No need to change this. The
> current 'problem' is to decide _how_ to plugin _which_ XML parser and
> whether this should be for reading and writing or only for reading.
>
> My point of view is (a) that the 'which' does not matter too much if
> the interface between the LyX core and such a parser is kept to a
> minimum [and the proposed 'MetaInset' would be a fairly slim interface]
> and (b) that we don't need any external help to _write_ XML.
I agree again with Andr�'s analysis here.
> Andre'
There is one other view of this discussion that no one mentioned yet. If
we decide to go full XSLT then the screen representation should be also
controlled this way.
This doesn't seems as simple as that, at least for a first step.
One idea that we have discussed several times in the LyX meetings, mainly
with Jean-Marc, is the generalization of our textclasses. Instead of having
an OutputType, that is one textclass is for latex, another is for linuxdoc,
and another for docbook we would an texclass with the output representation
for each backend. Something like:
Style Standard
# Linuxdoc
LinuxdocType Paragraph
LinuxdocName p
# LaTeX
LatexType Paragraph
LatexName dummy
# Plain Text
PlaintextType Paragraph
PlaintextName ""
# Docbook
DocbookType Paragraph
DocbookTypeName para
# Screen Representation
Margin Static
ParIndent MM
ParSkip 0.4
Align Block
AlignPossible Block
LabelType No_Label
End
IMHO this is the way to go, if later we go XSLT we should go all the way,
but for now I think it is too much.
What do others think?
--
Jos� Ab�lio Matos
LyX and docbook a perfect match. :-)
