Add a configuration parameter for the xsltproc processing to decide
whether to include hidden options.
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
Fix how the config option doc scripts behave when encountering elements
with blank titles (used to remove extraneous headings in the
configurator UI).
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
The acrn:views processing for showing which tabs an option would display
on wasn't quite right when an element AND a parent both had a views
attribute (specifically when the parent had "basic, advanced" but the
element only had "basic" or "advanced").
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
The configurator today shows "Please Input" as the placeholder of input
widgets, which is far from informative.
This patch specifies element or type specific placeholders in the XML
schema by reusing the `acrn:widget-options` annotation mechanism. For
manually-designed widgets such as ivshmem or vUART the placeholders are
added in the corresponding vue directly.
Tracked-On: #6691
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
Reduce expression complexity when searching for applicable-vms and views
annotations and increase ancestor search distance.
Don't sort glossary options to more closely mimic order found in the
configurator.
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
When an element in the schema does not have an acrn:applicable-vms or
acrn:views (as opposed to having the attribute with an empty value,
acrn:views="") we need to look up the ancestors to see if any of them
have an element with such an attribute defined. If non of the ancestors
have that attribute defined, then the intrepretation is that the element
can be found for all VMs or for both basic and advanced tabs.
Tweak the xslt processing of the schema data to option config doc to
reflect these semantics.
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
Change the generated config option documentation to use the DX-friendly
names defined for the configurator UI (instead of the XML element name
hierarchy previously used).
Options are grouped by the top-level section (aka complex type) they
belong to and then sorted alphabetically with these groups.
Use badges to indicate where options can be found in the configurator UI
and whether they're applicable to the Hypervisor or Pre/Post/Service VM.
Add a custom css style for the config-option doc that puts the first
paragraph of a glossary item on the same line as the glossary term so
these badges look pretty.
Added a acrn-custom.js patch that copies the alt text for images into a
title property for images within the config-doc document. This provides
tooltip text when hovering over the badges.
Don't display options not visible in the configurator UI (elements with
acrn:views="").
A missing acrn:views or acrn:applicable-vm means we look for an
applicable value from an ancestor element.
Add processing of a second xs:documentation element within an
xs:annotation element. This second documentation element's content will
be appended as a new paragraph to the first xs:documentation content in
the generated documentation. Only the first xs:documentation element is
used by the Configurator for its tooltips.
Update documents that were referring to options by their XML names.
Because we're now using a glossary to provide links to config options,
we can't duplicate option names or glosary names anywhere in the doc
set.
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
We plan to add the following attributes to element definitions in the XML
schema:
- acrn:applicable-vms, which specify if an element applies to a
pre-launched VM, the service VM or a post-launched VM
- acrn:views, which specify if an element shall appear in the basic or
advanced tab in the configurator.
In order to reduce the attributes above to existing XML technologies, we
need to create new complex types that lists all config items that applies
to a pre-launched VM, the service VM or a post-launched VM, or that should
be shown in the basic or advanced view. Such types can then be used to
replace the original, all-in-one type during validation or configurator
rendering.
When unspecified, an element always applies under all possible
circumstances.
To realize this slicing mechanism, this patch adds a generic class
implementing the common part of slicing XML schema types and two
specific-purpose slicers according to the applicable VMs or views
attributes.
v2 -> v3:
* Update configdoc.xsl to recognize types in xs:alternative nodes.
Tracked-On: #6690
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
Seperate options with simple types with a heading so they don't get
hidden under the previous options that are part of a complex type.
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
Some terms in the config option docs (Integer, Boolean) are being
flagged by one of our spell checking tools. Let's make it happy.
Tracked-On: #5692
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
Start cleaning up formatting and content layout issues in the
xsd-derived configuration option documentation. Includes adding
documentation for unnamed embedded simple types within an element (and
updates to the XSLT transformation to display these), cleanup of element
and type documentation, typos and description clarity.
Improved xsdl translation to automatically include default values and if
an option is optional (instead of manually documenting this in the
description text).
Tracked-On: #5692
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
Documentation for the scenario XML configuration options is pulled from the
schema definition files (xsd) maintained in the misc/config_tools/schema
folder. Update the doc build process to generate and incorporate the
option documentation.
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
