"Bo Peng" <[EMAIL PROTECTED]> writes:
| > Feel free to ask questions, and start some discussion...
|
| What are your design goals?
To change the lyx document format into well-formed and valid
(according to some dtd) XML.
| What are the benefits?
We get a well documented format that we can validate.
It should be easier to transform (XSLT etc) into other formats
(probalby lossy operation)
| Where is your
| format specification?
Basically the current lyx format and a DTD created from that.
(lyxformat.dtd in the branch)
| How does it relate to other XML formats? If not,
| why cannot it be similar to others?
Apart from being a XML format it probably does not relate at all. I
really think that our first version of the XML format should be based
more on the existing format than on some other out-in-the-wild format.
Sure we can use ideas from f.ex. odf. I have read through most of the
odf specification and we could use some parts, but it does not fit
perfectly.
| What has been done and what has
| not?
A dtd for something very similar to format verison 276 of the current
lyx format has been created. Saving in this XML format is done.
Export (write) of the UserGuide, Extended, External and Customization
has been tested against dtd with xmllint.
| Any implemented or planned converter (XSLT) to other XML formats?
I had hoped that some of the "export" formats that we have now, could
be moved out of the core source and be an xslt script instead. At
ascii export could do this easily, perhaps also docbook.
| How long do you expect it to be finished? What do you expect from us?
I have begun to look at the parser, and are thinking about what kindo
of parser we want/need. (validating parser is hight on my wish list,
but if it should be a dom-like or sax-like parser is more in the blue)
I would have hoped to get some help with cleaning up the remaining
parts of the DTD. there are currently (IMHO) to many CDATA and PCDATA
atrributs and elements.
Also help with the parser would be nice.
--
Lgb
