Class Def2Xslt


public class Def2Xslt extends Navigate.VisitReachable<Object>
Implements the extraction of all xslt rules for all definitions in a given module into the given target format. This is achieved by constructing an instance of this class (always anew, no re-usage) and then calling extract(Module,Module,String,String,XMLDocumentIdentifier,LocationMap,String,PrintWriter).

When parsing any d2d-encoded xslt source, namespace declarations. i.e. mappings from prefix to nsUri, are relevant in three(3) different concerns, and (luckily) non-relevant in some others:
  • The element structure of the d2d-encoded xslt source is parsed from d2d-tags, which are (possibly context sensitive) wordings, not including any namespace information. These yield elements, which in turn may have a namspaceUri in their xml encoding. This holds for both xslt elements and target elements. It holds for target formats given by a ddf or by a dtd (in that case the Dtd2ddf collects the namespace declarations by the tdom-pi, resolves the prefices into nsUris of the generated Definition and strips them.) The target model definition must be addressable by the normal d2d Module finding. The d2d xslt source identifies the top-level target model in its headline "d2d xslt producing XY".
  • In case of explicitly written, stand alone xslt files, the input xml model is present only in "match" patterns of templates, and in all xpath expressions in attributes of xslt elements and in attribute templates of some xslt elements and all result elements. The namespaces of the input model can NOT be derived from the d2d-data, and the prefix-nsUri-relation must be THE SAME as written/meant in the source text in the expressions. Since these are not analysed here, and thus no re-mapping of the prefices is possible, this relation must (a) be declared manually, by a "from"-declaration, must (b) be taken over to the resulting xslt model verbatim, and (c) must not conflict with any other declaration of this kind.
  • In case of an xslt source *extracted* from a "docu_to[]" entry in the d2d Module, the input model namespace uris are known, and the prefix COULD be re-mapped for the automatically generated top-level "xsl.template match='...'" attributes. BUT this does not hold for other xpath expressions written explicitly by the user in xslt attributes or result attribute templates, as described for the preceding case.
  • The same holds for third-party documents, inquired explicitly, eg. by xpath:"document(...)", with different nsUris internally.
  • The declarations of the input document in this "extracted" case are contained completely in the currently processed d2d Module and all its imported modules. For these, "from" namespace declarations are added automatically, by this code. The declaration of the target model is completely defined when resolving the key part of the "docu_to_[key]" into a d2d Module and will be identified by the generated headline.
  • All third-party ns mappings must be defined explicitly in the former! HOW ???? FIXME
The "meta" module will be extracted to the same target format, iff it is provided as an parameter.