'templates/XSDDoc/' subdirectory of each edition.
As being a commercial product, XSDDoc requires separate licensing. According to your license, it can work in one of three modes: limited, full or trial. For more details, please see Licensing / Processing Modes.
index.html
|
this file |
FramedDoc.tpl
|
The main template to generate framed HTML documentation. |
PlainDoc.tpl
|
The main template to generate single-file documentation (in HTML or RTF format). |
lib/
|
The directory containing all subtemplates (and icon files) that power the XSDDoc template application. |
xmltype/
|
The directory containing the XML schema for W3C XML Schemas:
XMLSchema.xsd and accompanying files. (All these files are available at
http://www.w3.org/2001/XMLSchema.xsd).
That XML schema serves as a critical part of the definition of the |
xsddoc.xmltype
|
The configuration file that defines the 'xsddoc' XML type,
on which all XSDDoc templates are based.
|
Note: All files and directories are located in 'templates/XSDDoc/' subdirectory of each edition of
DocFlex/XML.
Please note, some general functionality used in a given version of XSDDoc templates may be available only since a specific version of DocFlex/XML. In particular, the XSDDoc version 2.2.0 requires DocFlex/XML version 1.8.0 or later.
Depending on your license for "DocFlex/XML XSDDoc", the template set may work (be interpreted) in one of the three different modes: limited, full or trial.
| Note: | These are the processing modes of only the XSDDoc template application -- not the particular edition of DocFlex/XML (SDK or RE), which has its own processing mode(s). For more details, please see: http://www.filigris.com/buy/licensing_pricing.php | Commercial Template Applications |
In this mode, you can:
The limitations:
<img> tags).
What is more, you can also modify/customize the XSDDoc templates themselves (so as to add the functionality not implemented by us, change the generated content, look & feel and so on). For doing this, you will need an additional license for "DocFlex/XML SDK", which includes the Template Designer.
See also: http://www.filigris.com/buy/licensing_pricing.php | Multiple Licenses
It will be already pre-installed in the 'templates/XSDDoc/' directory of the main product.
(In the future, when other commercial templates applications will be developed, we may provide them as separately downloadable add-ons. However, now it is just an early stage of such a development.)
The only thing you may need specifically to install is the
'docflex-xml-xsddoc2.license' file, which contains your license
for "DocFlex/XML XSDDoc" template application.
You will receive that file by e-mail.
The license file should be stored in the 'templates/XSDDoc/' directory
along with the FramedDoc.tpl and
PlainDoc.tpl main templates
(i.e. those called the first by the generator).
After that, the 'XSDDoc/' directory will contain everything needed to
run XSDDoc.
Actually, the "DocFlex/XML XSDDoc" template application
is completely autonomous.
You can copy/move (or rename) the 'XSDDoc/' directory to any other location
and run the XSDDoc templates directly from there.
This may be particularly useful when you want to modify something in the original
templates and derive your own version of XSDDoc.
generator.bat (found in the root directory of your
DocFlex/XML SDK or
DocFlex/XML RE
installation). You will see the generator dialog.
While processing XSDDoc templates for big XML schemas,
the generator may be particularly hungry for memory. Lack of memory may considerably
increase the generation time!
To avoid this, make sure the maximum heap size available for JVM is 512Mb or even more
(e.g. Java option -Xmx512m sets the maximum heap size to 512Mb).
FramedDoc.tpl template.
You can choose this template from 'templates/XSDDoc' directory using File Chooser.
Each XML file can be specified either by local path name or by URL
(e.g. http://www.w3.org/2001/XMLSchema.xsd).
In the case of a URL, the generator will try to download such a file directly from the Internet.
When multiple XML files are specified, make sure that each pathname or URL is enclosed in double quotes.
The FramedDoc.tpl template is a frameset template
which can generate only HTML output!
Once all source XML Schema files are loaded, the generator enters into the estimation phase.
Lots of heavy processing is being done during that, however, you will see only
"Scanning data source, please wait..." message on the progress bar.
On large XML schemas this phase may take some time. Please wait!
After that, the generator will pass into the generation phase.
The progress bar will show what's being generated.
You can stop the generator at any time during any phase by clicking "Cancel" button.
We are always happy to hear any questions, suggestions, comments, etc.
about this product.
Please, e-mail us to:
support@docflex.com or
contact@filigris.com
A new "Content Model Diagram" section has been added in Component Documentation blocks. It shows a graphic diagram representation of the content model of the given component. The other XML schema components depicted on the diagrams will be hyperlinked to the corresponding sections/blocks across the entire documentation.
The section is generated by the lib/content/diagram.tpl template.
The diagrams are inserted using an Image Control specified to generate the "element image"
of the current DSM element representing an XSD component.
The actual diagrams may come from any kind of diagramming engine implemented outside DocFlex/XML core,
however connected to it via the Element Image Provider interface.
Currently, this is provided only by the
DocFlex/XML XMLSpy Integration,
which uses Altova XMLSpy® to generate the diagrams
(see also below).
In the future, other diagramming engines may be used or implemented.
See also:
{docflex-xml}/README.html | Change Log | Version 1.8.0 |
Template language / general functionality | Element Images.
When diagrams are supported, the "Content Model Diagram" section may be generated for the following component types:
The generation is controlled by a new parameter group: "Details | Component Documentation | Content Model Diagram", where you can specify if that section is included and how to generate diagram hyperlinks.
DocFlex/XML XSDDoc uses Altova XMLSpy® as a ready available diagramming engine to generate content model diagrams inserted in the XML schema documentation (see above). For that purpose, XMLSpy is actually called via two levels of integration.
The first level, called
"DocFlex/XML XMLSpy Integration"
itself, is hardcoded in Java. This is a separate commercial product with its own licensing.
For more details, please see {docflex-xml}/xmlspy/README.html.
The second level is implemented as lib/integrations/xmlspy.tpl template.
That template does not insert any diagrams in the output.
Rather, it is called only once by each of the main templates (FramedDoc.tpl and PlainDoc.tpl)
during the initialization (along with the lib/init.tpl template).
The job of xmlspy.tpl is to launch XMLSpy and cause it to generate component diagrams
for all XML schemas to be documented.
The template does this using special FlexQuery functions exposed by the integration hardcoded part.
(You can find those functions in the Template Designer via
Help | Assistant | Functions by Category | XMLSpy Integration Functions.
Note that they will be available only when the XMLSpy Integration is properly installed.
See {docflex-xml}/xmlspy/README.html | Installation)
Once diagrams have been generated, they are used further by the hardcoded part of the integration again and eventually become accessible in any other templates via Image Controls as "element images" (see above).
The template level of the whole XMLSpy integration is needed because of two reasons:
To control the XMLSpy integration, a new parameter group have been added: "Integrations | XMLSpy"
The documenting of redefined XML schemas has been reworked.
In particular, before now, the components being redefined were renamed by adding "$ORIGINAL" suffix
(so as to distinguish the redefinition from the original components).
After that, such a suffix was visible everywhere (including in the reproduced XML source),
which might be looking confusing.
Now, such a renaming never happens. The reproduced original XML source looks the same as the original one. (However, all hyperlinks are correctly generated to the redefinitions instead of the original components.)
In the documentation itself (in various lists etc.), the original components are shown with their original names only. The redefinitions are represented with the component original names followed by "(redefinition)" or "(redef)" string. For example:
xhtml.a.attlist (redef)Nested redefinitions are also supported. Their names will be extended with "(redef 2)", "(redef 3)" etc.
The new processing of redefinitions was implemented using "service attributes" general functionality
added since DocFlex/XML v1.8.0. See
{docflex-xml}/README.html | Change Log | Version 1.8.0 |
Template language / general functionality | Service Attributes.
New parameters have been added to control whether a relative or absolute XML schema file path must be displayed in the documentation and whether to generate the hyperlink to the source XML schema file.
Relative Path
Specify whether to display schema location as a relative pathname. When this parameter is selected (true) and the schema file resides on the local system, the file pathname will be converted to a relative one against the documentation destination directory.Hyperlink
Specify whether to generate a hyperlink to the schema file. When this parameter is selected (true), the schema location text will be hyperlinked to the actual schema file. When the displayed schema location is a relative pathname, the hyperlink is generated relatively to the location of the given document file. Otherwise, the hyperlink is generated to an absolute URL either on the local system or remote one.Those parameters can be found by the following parameter paths:
Your XML schema project may contain both XML schemas with annotations formatted using XHTML and those with plain text annotations. In the case of plain text, the only formatting available are new lines. When XHTML is processed, the new lines are ignored. So, how can you generate documentation in which the both formatting approaches are used?
Now, you can do this by specifying which XML schemas use XHTML and which do not. Two parameters have been added:
Processing | Annotations | XHTML | For schemas | Include
Specify the list of XML schemas whose annotations may contain XHTML markup.Processing | Annotations | XHTML | For schemas | Exclude
Specify the list of XML schemas whose annotations contain no XHTML markup (or it should ignored).
The automatic extraction of first sentences of the annotations formatted with XHTML
has been improved. For more details, see
{docflex-xml}/README.html | Change Log | Version 1.8.0 |
Template interpreter / output generator | Extraction of first sentence from HTML formatted text.
The extensions of local element names now are shown entirely in grey color, including hyperlinks. (Hyperlinks are indicated with underlining.) This should make the generated documentation to look more tidy and easy to read.
Note: The generation of local element name extensions are controlled by "Show | Local Element Extensions" parameter. See also: Version 2.1.0 | Documenting of local elements | Showing extensions of local element names.
New parameters have been added to control how various lists of components are arranged. A list may be represented either as a comma-delimited text flow, which is more compact but harder to read, or as a two-column table, which is easier to read but occupies more place. The following parameters allow you to choose between those two possibilities depending on the schemas you document:
These new parameter groups allow you to specify exactly for which components the "XML Representation Summary", "Lists of Related Components", "Usage / Definition Locations" and "Annotation" section must be generated. This may be separately selected for the following component types: elements, complex types, simple types, element groups, global attributes, attribute groups.
Specify for which components the "Attribute Detail" section is generated (e.g. elements, complex types, attribute groups) and which attribute definitions may be included in it (e.g. local attributes, references, wildcard, prohibitions, the attributes inherited from ancestor components).
Specify for which components the "Content Element Detail" section is generated (e.g. elements, complex types, element groups) and which element definitions may be included in it (e.g. local elements, references, wildcards, the elements inherited from ancestor components).
These parameters control whether to include Facet Documentation.
The full processing mode, which is activated under a Commercial or Academic License for "XSDDoc" template application, since this version unlocks all available functionality of the XML schema documentation generator. This includes what is both implemented in the templates themselves and supported by the DocFlex/XML template iterpretor / output generators.
No other licenses will be needed for this!
Previously, to use certain features supported by some output format generators (e.g. rendering in RTF the XHTML markup embedded in XML schema annotations), an additional license covering the DocFlex/XML generator was needed.
Now, DocFlex/XML RE, which was continued from the early "DocFlex/XML (Kit)" edition, provides free template interpretor / output generators.
This mode, which is activated by default without any special licenses, now enables only using of FramedDoc.tpl main template.
So, you can generate with it for free some standard (however, absolutely complete) multi-file framed XML schema documentation in HTML format (with limited possibilities of customization).
No other types of documentation (including RTF) can be generated in the limited mode.
XML catalogs are used in XML schema projects to avoid referencing XML schemas from each other
(via <xs:import>, <xs:include>, <xs:redefine> elements)
by direct file names. Instead, only some abstract URIs representing the schemas are used for that purpose.
The URIs are connected to the actual
XML schema files in a special XML catalog file. This makes possible to break the entire XML schema into a number
of XSD files (modules) and do not care further about their particular locations.
As an example of the XML schema project that uses the XML catalog see this link: http://docs.oasis-open.org/dita/v1.1/OS/schema/ditaschema.zip
Now, XSDDoc allows you to generate the complete documentation by such XML schema projects as well !
When an element is affiliated to a substitution group and the element type is not specified,
inheriting the type from the head element of the substitution group
(specified with substitutionGroup attribute).
Generation of the list of elements which the given element may substitute for. (That is, the given element may be used anywhere instead of the elements in the list.)
Controlled by the parameter: "Details | Component Documentation | List of Related Components | Substitutable Elements"
Generation of the list of elements which may substitute for the given element. (These are the members of the substitution group headed by the given element.)
Controlled by the parameter: "Details | Component Documentation | List of Related Components | Substituting Elements"
Generation of the list of all known elements that may be included in the given element by substitutions.
Controlled by the parameter: "Details | Component Documentation | List of Related Components | Children By Substitutions"
Generation of the list of all known elements that may include the given element by substitutions.
Controlled by the parameter: "Details | Component Documentation | List of Related Components | Parents By Substitutions"
In the element's "Usage Locations", generation of the list of elements where the given element
is specified as the value of the substitutionGroup attribute.
Note: All the lists are produced according to the values of substitutionGroup
and block attributes of global element components (as well as considering
blockDefault attribute of <xs:schema>).
The abstract attributes specified on global element and complex type components
are documented now in the component profile sections.
Moreover, anywhere an abstract element or complex type is mentioned in the documentation,
its name will be highlighted with italic font.
block and final attributes of elements and complex/simple types
Those attributes are documented now in profile sections of corresponding components (with possible explanations).
The block attributes are used also to calculate actual members of substitution groups.
The blockDefault and finalDefault attributes of <xs:schema>,
which provide the default values of the block and final attributes of elements and types,
are taken into account and documented in XML schema profile as well.
nillable attributes of elements
(in profile sections of element documentation and content element details)
These files/blocks are organized the same as similar ones generated for particular XML schemas or namespaces, however, now they list all documented XSD components (i.e. those for which separate Component Documentation blocks have been generated).
Actually, the exact content of the "All Component Summary" document can be specified in "Details | All Component Summary" parameter group.
A template parameter "Show | Namespace Prefixes" has been introduced to switch on/off showing namespace prefixes in the names of XML schema components being documented or mentioned in the documentation.
Any namespace prefixes used in the output documentation originate from the namespace URI/prefix bindings declared in the source XSD files. For a particular XML name, its namespace prefix is generated according to the binding for the given namespace found the nearest to the documentation context where that XML name appears.
Previously, such prefixes were generated in any case. However, sometimes the XML schema authors may declare very long namespace prefixes (even without actually using them), which would completely overwhelm the documentation. So, the showing of such prefixes needs to be switched off in that case.
The settings of elementFormDefault and attributeFormDefault attributes
specified in the <xs:schema> element are documented now in the
XML schema profile.
You may specify which information is included in the XML schema profile, for instance, in the parameter group "Details | Schema Overview | Schema Profile".
The local elements with the namespace-unqualified form are documented now as belonging to global namespace. Previously they were still linked to the namespace targeted by the parent schema (where they are declared).
A template parameter "Show | Local Element Extensions" has been introduced to control the generation of the extensions of local element names.
The extended name of a local element is made of its normal name extended with some short info about the possible element location or its type. For example:
configuration (in plugin in plugins in reporting)
xs:complexType (type xs:localComplexType)
here in the brackets are the local element name extensions.
The name extensions are needed to distinguish the element in the documentation from other local elements, which share the same XML names, however have different content.
The name extensions may be not necessary for local element with unique names. For instance, some XML schemas are designed (or generated) so that almost all element components are declared locally, except only the root element. At that, all element names may be unique. So, the name extensions are not really needed and will only overload the documentation.
Before this version, the extensions of local element names were generated in any case. Now, it is also possible to specify not generating them at all or generating them only for local elements with non-unique (repeating) names.
A unique feature of this XML schema documentation generator (XSDDoc) is the possibility to document local elements both locally and globally. (For more details see parameter: "Generate Details | Elements | Local Elements".)
In the case of global documenting, all local elements that share the same { namespace, name, type } are documented as a single quasi-global element. This is possible because many things that can be said about each particular local element component covered by it are the same. Documenting them together as a single entity may actually reveal more information.
However, there are a few things that may vary at each particular location. Annotations are among them.
Now, the unified quasi-global element documentation will list all annotations specified locally at each covered local element component. At that, when the annotation text actually repeats, it will be printed only once with the list of all locations where such a text was specified.
From the very start, XSDDoc has been able to recognize and process the XHTML tags (elements) embedded in any XML schema annotations (so as to format with HTML the annotation text and include images).
It was only required that any markup elements supposed to be XHTML were actually associated with
the XHTML namespace URI http://www.w3.org/1999/xhtml that must be specified with
'xmlns' attribute. (For more details, please see
DocFlex/XML | XSDDoc | FAQ | How to use XHTML?)
Switching to XHTML namespace would be always correct from the point of overall XML integrity. However, since many people actually want to use HTML tags without bothering much about all those namespaces, we have eased that requirement.
Now, you can use HTML tags directly without switching the context namespace to the true XHTML. To have such tags to be processed as XHTML, you will need
true)
"process as XHTML".
An additional parameter has been introduced related to HTML markup: "Processing | Annotations | Encode markup characters". It controls whether to encode the HTML markup characters contained in the annotation text.
The purpose of this parameter is the following:
A < B'<' character as it is.
Since the whole annotation will be converted into HTML, that character needs to be encoded.
In that case, this parameter should be selected.
<xs:annotation>
<xs:documentation>
This is <b>keyword</b>
</xs:documentation>
</xs:annotation>
An XML parser will convert such an annotation text into the string:
This is <b>keyword</b>
which could be immediately passed to an HTML viewer or added to HTML output.
In that case, the HTML markup characters should not be encoded!
Therefore, if you have an XML schema like this, you should unselect this parameter. (An example of such a schema you can find by this link: http://maven.apache.org/xsd/maven-4.0.0.xsd)
In fact, XML schema <xs:annotation> element does not allow inserting the annotation text directly into it. Instead, XSD language defines its two possible children: <xs:documentation> and <xs:appinfo> elements.
It is the <xs:documentation> elements where you actually put the human-readable text.
The <xs:appinfo> elements are supposed to store the data or instructions intended for some software that would process the XML schema. Because of this, generally, it is unclear how <xs:appinfo> elements should be documented (except of reproducing their XML source as is).
However, some people want to use <xs:appinfo> elements in the same way as <xs:documentation> elements and place the human-readable text there too. For such people, we have supported a possibility to process the <xs:appinfo> elements in that way as well. It is controlled by the new parameter: "Processing | Annotations | <xs:appinfo>"
A new parameter group "Generate Details | For Schemas" has been supported that allows you to specify which XML schemas (and their components) are to be documented.
The XML schema files you initially specify on the command line (or in the generator dialog) are the primary XML files to be processed by the XSDDoc template set.
However, those initial XML schemas may call from themselves some other XML schema files
(via the <xs:import>, <xs:include> and
<xs:redefine> elements) and they, in turn, yet more extra schemas.
All those extra XML schema files plus the schemas specified initially will constitute
the whole your XML schema project. Generally, all of them must be loaded and processed
in order to make sense of your initial XML schemas (that is, to interpret and document them).
Some of such imported extra XML schemas may be the standard ones used in other your projects
(in addition, they may be rather big).
Before this version, all the extra XML schemas involved in your project would be fully documented as well. But what if you actually want to document only the explicitly specified XML schemas?
Now, you can do it using the new parameters in "Generate Details | For Schemas" group!
Using PlainDoc.tpl main template, you can document now
not only the whole XML schema but to generate separate documentation for several selected (or even single)
XML schema components (e.g. elements, global complex/simple types, groups, etc) specified by their local names.
For instance, the parameter "Generate Details | Elements | Names" available in
PlainDoc.tpl
allows you to specify directly the names of the elements to be documented in separate
Element Documentation blocks. When the list of names is specified, only the element components
with the specified names will be documented.
The same is supported for other component types.
A new parameter "Details | Component Documentation | XML Representation Summary | Sorting" (and even some general template language functionality for it) has been supported to specify sorting of attributes shown in the XML Representation Summary of a component (e.g. element).
When the parameter selected (true), the attributes will be sorted
in alphabetic order of their qualified names.
When unselected (false), the attributes will follow according
to some natural order determined by how and where the attributes have been defined.
In a simplest case, when all attributes are defined within the same component,
that will be exactly the order of their definitions. When the given component
(whose attributes are represented) is based on other components, some of such ancestor components
may define particular attributes (and even block some of those defined within their own ancestors).
In that case, the result attribute ordering will appear from the subsequent interpretation of
all involved components.
Thanks to DocFlex template technology, overall, it was possible to support more than 300 template parameters (working the same as "options" of an ordinary documentation generator), which gives you an unprecedented control over the content, look & feel of the generated XML schema documentation!
Since this version, XSDDoc becomes a commercial template application, that is a separate commercial product with individual licensing and its own version numbering.
The system of parameters that control XSDDoc has been entirely reworked. The total number of parameters now exceeds 170. This will allow you to control almost every aspect of the generated XML Schema documentation and vary its content (and some formatting) within a great range of details, starting from a few summaries and overviews up to the most comprehensive documentation containing every feature possible.
On the other hand, such a large number of parameters should not hinder you because all of them have the default values, some of which are calculated dynamically from the values of other parameters.
What is more, thanks to the new capabilities of the Template Parameter Inspector introduced in the latest DocFlex/XML v1.7.0, all parameters of XSDDoc are organized in the form of a hierarchical tree (with dynamically collapsed/expanded nodes) that is both compact and easy to use.
Before this version, the local elements (i.e. the element components defined locally within complex types and groups) were documented in the same way as the global ones. The emphasis was to treat each pair { local element name : type } as a quasi-global element so as to collect and document about such a pair all the information possible.
That approach worked well for many big XML schemas (e.g. like "XML Schema for XML Schemas" found at http://www.w3.org/2001/XMLSchema.xsd) and helped to reveal lots of information about the XML elements defined by the schema.
However, for certain types of XML schema design, documenting of local elements along with the global ones is not good and, rather than clearing things up, may produce a mess. This is especially true when the XML schema authors avoid defining element attributes. Instead, in order to store the elementary data normally supposed for attributes, they define lots of local elements with primitive simple types. As a result, such an XML schema contains great a lot of insignificant local element components. When all of them are documented separately (and appear in all element component lists) they may overwhelm anything else. In that case, such local elements need to be documented locally, exactly where they are defined!
XSDDoc now supports this. The local elements can be documented simultaneously in two ways: locally and globally. The local documenting means that the element component is documented together with its parent component (where it is defined). The details about the element will appear in the "Content Element Detail" section of the Component Documentation generated for its parent component.
That was before this XSDDoc version, of course. However, now a lot more details (almost all) about each element can be included in the "Content Element Detail" section as well. Which exactly details are generated is controlled by the parameter group: "Details | Component Documentation | Content Element Detail".
What is more, the parameter "Generate Details | Elements | Local Elements" allows you to specify whether to document local elements separately (globally) and which of them. For instance, if this parameter is set to "with complex type only", then the local elements with simple types (which normally substitute attributes) will be documented only locally. That will allow you to avoid the mess mentioned above.
Now, for all situations when a simple content (i.e. simple datatype) is used or defined:
the following details can be generated:
The list of actual facets is produced as the following.
First, the initial facets are collected by all types starting from the type assigned to the component throughout the chain of all its ancestor types (both global and anonymous) until the top ancestor passed or a derivation by list or union reached. Further, the produced sequence of facets is filtered so as the facets collected earliest (that is defined in lower descendant types) remain and those overridden by them are removed. In particular:
xs:pattern facets will remain, because the allowed value must match all of them.
xs:enumeration facets will remain only those that are defined in the same type,
which is either the component's type itself or the one nearest to it.
When you need to annotate your XML schemas simultaneously in several languages,
you should use several sibling <xs:documentation> elements with
different xml:lang attributes. For example:
<xs:element name="author" type="author">
<xs:annotation>
<xs:documentation xml:lang="en">
The author of a book.
</xs:documentation>
<xs:documentation xml:lang="fr">
Designe l'auteur d'un livre.
</xs:documentation>
</xs:annotation>
</xs:element>
Now, XSDDoc will allow you to use such multi-language annotations
to generate different variants of the same XML schema documentation for different target languages.
When you specify the target language code in the "Processing | Annotations | Language"
template parameter,
only those <xs:documentation> elements will be processed,
which contain the xml:lang attribute assigned with that code.
<xs:any> and <xs:anyAttribute>
wildcards are fully documented now (the same like other elements and attributes).
xmlns attribute in <xs:schema>
element) includes another schema using a <xs:include> or
<xs:redefine> directive and the included schema has no default
namespace specified. Such a situation happens in case of so-called "chameleon design",
when the included/redefined schema is assumed to adopt the default namespace of
the calling schema. Before v1.6.8, the XSDDoc did not process it accordingly,
which caused generating a wrong documentation. Now, it is fixed!
<xs:import>,
<xs:include>, <xs:redefine> directives.
lib/init.tpl template,
which caused the attributes specified within a child element defined locally within
another element to be documented also as the attributes of the parent element.
PlainDoc.tpl and
FramedDoc.tpl templates to remove
<xs:annotation> elements from the reproduced XML source
(see in parameter inspector "Sections | XML Source | Remove Annotation").
This can by controlled specifically for different types of XML source fragments
(e.g. for components the annotation can be removed, but the full XML schema source
will be reproduced as is).
<img> tags) in XML schema annotations.
The XSDDoc templates are upgraded now to support
the XML Schema annotations (the content of <xs:annotation> elements)
preformatted with XHTML tags, including possibility to insert images
(using <xhtml:img> tag).
The processing of XHTML tags is programmed entirely within annotation.tpl
subtemplate (located at templates/xsddoc/misc/ directory).
All XHTML tags are converted to the normal HTML tags (actually, just
'xhtml' namespace prefix is removed from the tag names).
Further, everything is processed by the generator itself.
In the case of HTML output, each annotation text together with HTML tags is inserted
as is into the generated output file. Additionally, the image files specified in
<xhtml:img> tags can be copied automatically to the documentation
destination directory. This is also programmed in annotation.tpl subtemplate
and controlled by "Formatting | Annotation | Copy images" parameter of both
PlainDoc.tpl and
FramedDoc.tpl main templates.
In the case of RTF output
(generated with PlainDoc.tpl template),
all HTML tags embedded in annotations are parsed and interpreted with the appropriate
RTF formatting features. Almost all HTML tags (and their attributes) practically
usable in documentation comments are processed in that way. Here's the list
of all supported HTML tags:
| Text | <b>, <strong>, <i>, <em>, <code>, <tt>, <u>, <s>, <strike>, <sub>, <sup>, <font>, <br> |
| Paragraphs | <p>, <center>, <div>, <pre>, <h1>, <h2>, <h3>, <h4>, <h5>, <h6>, <blockquote> |
| Lists | <ul>, <ol>, <li>, <dl>, <dt>, <dd> |
| Table | <table>, <tr>, <td>, <th> |
| Other | <hr>, <img>, <a>...</a> |