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
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.