All pages: introduction message/location/muli format dtd xantlr tdom ops paisley metajava umod option auxiliaries d2d downloads & licenses people bibliography APPENDICES:: white papers white papers 2 white papers 3 project struct proposal SOURCE:option.dtd SOURCE:dtd.umod DOC:deliverables.ddf DOC-DE:deliverables.ddf DOC:mtdocpage.ddf DOC-DE:mtdocpage.ddf DOC-EN:lablog.ddf SOURCE:basic.dd2 DOC:xslt.ddf SOURCE:xslt.dd2 DOC:meta.ddf [site map]

white papers 2	bandm meta_tools	project struct proposal

Collected White Papers on Technical Details --3--

1          Applications and Self-Applications, a Survey
1.1          Table of Usage
1.2          Some paradigmatic data flows

^{^ToC} 1 Applications and Self-Applications, a Survey

^{^ToC} 1.1 Table of Usage

The following table does NOT mention the usage of ops, format, message, dtd, dtm and many other smaller packages, because these are ubiquituously engaged. The intention is to point out some paradigmatic applications of the larger functional unities of ^meta_tools , which can be helpful for the uses as examples, documentation and inspiration.
A tabelaric survey is followed by some more detailed graphs of data flow.

Remarks:
(X1) metajava/the users of metajava heavily use "format", but not the front-end compiler.
(X2) tdom uses "option" after a second bootstrap cycle.
(X3) users of "muli" and "option" frequently use "d2d", after completion of the bootstrap cycle.

^{^ToC} 1.2 Some paradigmatic data flows

A very versatile pattern is the following, which happens in the complete and in a shortened form:

                         ]
                     d2d ]           tdom               javac
 <inputFormat>.ddf  -----]--> <iF>.dtd -------> <iF>.java -----> <iF.class>
                         ]

                          <input>.xml----\
                     d2d                  \                    HANDCODED
 <input>.d2d ----------------->sax---------+--> objectModel ===============> output
                                     tdom          \                   /
                                                     ----> aux Data --
                                                      HANDCODED   

The long form works as follows:
Nearly all sources are generated from an initial ".ddf" d2d-text-type definition automatically.
The input data is encoded in d2d format and directly fed into the tdom model, with a few lines of top-level code.
The "auxData" are "diagonal vertices" in the tdom graph, i.e. additional directories, maps, indexes, etc., constructed by hand coding.
In most cases this pattern is very efficient: only few additional data must be generated, the generated visitor pattern can heavily be exploited, resulting in few lines of user code.

eu,bandm.book2, de.na-berlin.meeli, and eu.bandm.cooking work this way.

An esp. interesting case is when an XHTML model is the generated output (eu.bandm.cooking). Here one tdom model is transformed into a different one.

The method which realizes the functionality of "data 2 tdom", callable by alle these applications, is static eu.bandm.tools.d2d2.base.Tasks.text2tdom(..) .

The most complex example is the BandM txsl xslt interpreter: its operation is nothing more than a transformation (expansion) of the original tdom model of the xslt code.

The shortened form starts with a DTD for generating tdom.
The input data normally is an XML file, in the standard encoding.
Nevertheless, this file can also be generated by d2d parsing, controlled by the dtd.
This pipelining can happen internally, controlled by the application, or externally in the file system, controlled by "make" etc. This does not make any difference in the logical of the data flow.

In this way tools.option and tools.muli are implemented. They are used as follows

white papers 2	bandm meta_tools	project struct proposal

made    2025-01-08_22h19   by    lepper   on    happy-ubuntu       

produced with eu.bandm.metatools.d2d    and    XSLT    FYI view page d2d source text