() Patrice Dumas <[email protected]> () Thu, 29 Nov 2012 13:22:52 +0100
> 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.) 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. Sorry, i was imprecise. We have basically the same idea, that makeinfo be the authoritative source for some "to be defined as we go along" file format. 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. IXIN proposes one format, and includes tools for writing and reading it, but those are just to play around, to inform the file format design. The end product of this exercise is primarily the format spec and not the toy tools. How non-toy programs are implemented to read (but not write, since that is makeinfo's purview) such files is not important. > 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. It seems the (S)XML alone is not sufficient. IXIN 1.0 and 1.1 only modified the (S)XML a little, by dstructively extracting ‘nodename’ and the link elements node{next,prev,up}, as leaving them in each ‘node’ is redundant. These releases left ‘meta’ more or less undisturbed. IXIN 1.2 turns further away from (S)XML in ‘meta’, which now looks like: (ATTRS XID VARS SETTINGS COPYING TITLEPAGE ELEMENT...) In particular, XID, VARS, and SETTINGS are not (S)XML, but in a format less-tediously accessible (simple lists, and association lists). These are described in the README. 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. Is there a strict 1:1 correspondance between elements of the sectioning tree and elements of the node tree? Can a section have zero or multiple nodes? Can a node have zero or multiple sections? Presently, in META, the last element is usually ‘(contents (@))’. How about replacing that element w/ the sectioning tree? Another idea is to place it after the index, so that the file format looks like: MAGIC META COUNTS INDEX S-TREE NODES Maybe that would be more straightforward, since S-TREE can refer to the node indices (0 for "Top", etc), then. * 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? Some of these are in XID, The rest could go in SETTINGS. * 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', These could go in SETTINGS, too. 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). Hmm, i suppose there should be another place to specify nodes that modify settings. The processor must accumulate these. Something like: ... INDEX S-TREE (TWEAK...) NODES where TWEAK is ‘(INDEX (NAME VALUE)...)’. In this case, we could actually move (some of the) SETTINGS out of META and into the list of TWEAKs, as the first one: ‘(0 (NAME VALUE)...)’. If "Top" has its own tweaks, those would have to be merged -- no big deal (i think). * index of indices entries. At least the node containing the indices entries (@cindex...) should be indexed somewhere, to be able to format a printindex. Agreed -- see TLI in COUNTS. E.g., hello.ixin says ‘((cp 6))’. Or am i misunderstanding something? I that that it would be even better to have an XML representation of the index entry text. Yes. That info should lie in the node, i'd think. 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. I see you revisited these thoughts in other posts; i will do likewise. -- Thien-Thi Nguyen ..................................... GPG key: 4C807502 . NB: ttn at glug dot org is not me . . (and has not been since 2007 or so) . . ACCEPT NO SUBSTITUTES . ........... please send technical questions to mailing lists ...........
pgpcAGJCydfrc.pgp
Description: PGP signature
