I've pushed an update to lyx2xml in my clone of lyx that uses XML
namespaces for layouts and insets, and which supports math (though it
doesn't output MathML, sadly, not yet).
So now the XML output looks more like this:
some text
Whatever
and so on.
This is much nicer than the earlier version'
On Thu, Dec 27, 2012 at 11:22 AM, Richard Heck wrote:
> On 12/26/2012 01:03 PM, Nico Williams wrote:
>> Granted, if I had a faithful XML schema equivalent of .lyx then version
>> changes could break my XSLs. But I could work around that via XSLs to deal
>> with version changes, but I think that's
On Thu, Dec 27, 2012 at 4:29 AM, Vincent van Ravesteijn wrote:
>> I'm not proposing XML as the native format.
>
> In my opinion, there is only a small step between having a "faithful .lyx
> format" and a "native LyX format".
But having a faithful XML version of .lyx is only a step in that
directi
On 12/27/2012 05:29 AM, Vincent van Ravesteijn wrote:
b) Changing .lyx to be native XML. I think the only way how to
get 100% faithful
and stable/robust conversion.
That might well be nice, but I don't need this and I'm NOT asking for
this, much less offering to implement this. lyx2
On 12/26/2012 01:03 PM, Nico Williams wrote:
Granted, if I had a faithful XML schema equivalent of .lyx then
version changes could break my XSLs. But I could work around that via
XSLs to deal with version changes, but I think that's quite tolerable
(and no different than LyX's existing .lyx ver
Am Mittwoch, 26. Dezember 2012 um 14:02:55, schrieb Nico Williams
> On Dec 26, 2012 5:46 AM, "Pavel Sanda" wrote:
> > The problem is that once we ship it under LyX flag officially we are
> > responsible to fix its bug and maintain it in future. That's why so
> > much fuss around.
>
> One more t
Vincent van Ravesteijn wrote:
>> I also want to round-trip through XML for 3-way diff/merge purposes,
>> but this is farther into the future. Everyone seems to agree that the
>> minimal existing diff functionality in LyX sucks,
>
> .. because it gives a too optimal solution. I think I will need to
We are on completely different ground if we start discussion about using XML as
native format. I'm sceptic that your approach would be used, but that was just
IMHO, we use pythonic lyx2lyx creature right now after all. At the moment
there is no one who really works on this goal and as you could
Nico Williams wrote:
> No, it doesn't. I've tried. I need more metadata than Docbook knows.
> Please either be much more specific about how to make Docbook meet my
> needs or accept my explanations for why it won't do.
Ah, somehow I didn't catch that you already discovered it's impossible
to sp
On Wed, Dec 26, 2012 at 5:54 PM, Pavel Sanda wrote:
> Nico Williams wrote:
>> future XML document conversions based on XSLT, I think once you familiarize
>> yourself with XSLT you'll agree with me that it's much better and easier to
>> use XSLT than to write C++ to do the same task.
>
> I no way I
Nico Williams wrote:
> future XML document conversions based on XSLT, I think once you familiarize
> yourself with XSLT you'll agree with me that it's much better and easier to
> use XSLT than to write C++ to do the same task.
I no way I wanted to trigger religious war about the best language. My
On Wed, Dec 26, 2012 at 2:02 PM, Nico Williams wrote:
> On Dec 26, 2012 5:46 AM, "Pavel Sanda" wrote:
>> The problem is that once we ship it under LyX flag officially we are
>> responsible to fix its bug and maintain it in future. That's why so
>> much fuss around.
>
> One more thing: with a few
And my script is a Python script. It enables the use of XSLT by producing
XML, but no knowledge of XSLT is needed to support that script. As for
future XML document conversions based on XSLT, I think once you familiarize
yourself with XSLT you'll agree with me that it's much better and easier to
Regarding Docbook... if it can preserve all LyX metadata, including custom
insets and such and not lose much in a round-trip conversion, great, but I
suspect it can't. Really, you need an XML schema that is as closer an
analog of .lyx as possible.
XSLT is not going away. Reproducing its power in
Nico Williams wrote:
> And that (document class affecting details of LyXHTML output) is as it
> should be for a presentation format, but it's a disaster for a
> document format.
Yep, your point is clear, that's why I asked about DocBook -- I'm not
using it but from the few bits I have seen it look
On Dec 26, 2012 5:46 AM, "Pavel Sanda" wrote:
> The problem is that once we ship it under LyX flag officially we are
> responsible to fix its bug and maintain it in future. That's why so
> much fuss around.
One more thing: with a few simple rules we can make lyx2xml a maintenance
fee script. The
Also, not to belabor the point, but one of the things I want to be
able to do is import from XML. LyXHTML, as a presentation format, is
not a very good choice for generating .lyx from.
On Wed, Dec 26, 2012 at 5:45 AM, Pavel Sanda wrote:
> Nico Williams wrote:
>> I've filed a request for enhancement so that external "plugins" can be
>> found by configure.py.
>
> Sure, I know. What I don't know is whether or when someone will pick it up and
> implement it. Changing configure.py is
Nico Williams wrote:
> On Tue, Dec 25, 2012 at 7:50 PM, Pavel Sanda wrote:
> > I think we can support your converter via recognition in configure.py
> > so XML convertor appears in View/Export menus when installed.
> > We can also put it in contrib section on our ftp server, if you would like.
>
On Tue, Dec 25, 2012 at 7:50 PM, Pavel Sanda wrote:
> I think we can support your converter via recognition in configure.py
> so XML convertor appears in View/Export menus when installed.
> We can also put it in contrib section on our ftp server, if you would like.
I've filed a request for enhanc
Hi Nico,
Nico Williams wrote:
> My script works around all those issues and is complete enough (if a
> bit ugly) that I can show it to you folks and let you decide if this
> is something that you want to pursue. Personally I'm convinced that
> is a truly faithful-to-the-original-.lyx XML export f
21 matches
Mail list logo