On Thu, Nov 29, 2012 at 04:17:55AM +0100, Thien-Thi Nguyen wrote: > > Since this last exchange a couple months ago, i've tried to answer "in > which format" by playing w/ code. (I agree that makeinfo should be > hands-off, for the most part, btw.) If you get a chance, please see:
I had the opposite idea. To me, the idea was that makeinfo would generate both the XML that describe the nodes, and the IXIN file that describes the whole document. All the code is already there, since makeinfo basically has in memory all this information to be able to do the HTML output. If you want to have the code as lisp, sure it won't be convenient, but doing it in makeinfo/texi2any should be very simple, using the XML backend for the nodes, and the code used for HTML for the indices as it is very similar. > http://www.gnuvola.org/software/ixin/ > > I think the priority is to define the "container shape", which is what > IXIN 1.0 aims to do; precise design / interpretation of the (S)XML-ish > contents can be done later. What do you think? A agree, although I think that using the texinfo XML would be the correct thing to do: if it is not suitable, that would certainly show that it has to be modified. Some remarks: * sectionning tree. I think that, in addition to the node tree, the sectionning tree (@part, @chapter, @section, @unnumbered...) should be present and index the corresponding nodes too. * the meta part is not completly clear to me. Is the idea to have a container for information set for the whole document: 'documentdescription', 'evenfootingmarks', 'evenheadingmarks', 'everyfootingmarks', 'everyheadingmarks', 'fonttextsize', 'footnotestyle', 'novalidate', 'oddfootingmarks','oddheadingmarks', 'pagesizes', 'setchapternewpage', 'setcontentsaftertitlepage', 'setfilename', 'setshortcontentsaftertitlepage', or something else? * if you want 'random' access to nodes, you need to also give some information on the document state at the beginning of the node. Roughly, this corresponds to 'allowcodebreaks', 'clickstyle', 'codequotebacktick', 'codequoteundirected', 'deftypefnnewline', 'documentencoding', 'documentlanguage', 'exampleindent', 'firstparagraphindent', 'frenchspacing', 'headings', 'kbdinputstyle', 'paragraphindent', 'urefbreakstyle', 'xrefautomaticsectiontitle', And the processor should be able to process an information of a change in those. Some may not be needed, in fact if the information is already in the XML (for instance, I think clickstyle is also in an attribute of @click or something like that). * index of indices entries. At least the node containing the indices entries (@cindex...) should be indexed somewhere, to be able to format a printindex. I that that it would be even better to have an XML representation of the index entry text. A last remark, using a base64-encoded gzipped nodes representation seems weird to me, why not simply an xml file per node with a file name constructed similarly as for html, with additional care for avoiding to have different nodes in the same file? Is the point having everything in only one file? For the index entries, maybe the base64 stuff would be useful for rapid direct access. -- Pat