Configuring the Proposals for Attribute and Element Values
Oxygen XML Editor includes support for configuring the proposed values that appear in the Content Completion Assistant. To do so, a configuration file is used, along with the associated schema, to add or replace possible values for attributes or elements that are proposed in the Content Completion Assistant.
For an example of a specific use-case, suppose that you want the Content Completion
Assistant to propose several possible values for the language code when you use an
@xml:lang
attribute.
Setting up the Content Completion Configuration File
- Create a new resources folder (if it does not already exist) in the frameworks directory for the particular document type (for example, OXYGEN_INSTALL_DIR/frameworks/dita/resources).
- Open the Preferences dialog box and go to Document Type Association. Select the particular document type, click the Edit button, and in the Classpath tab add a link to that resources folder (if it does not already exist).
- Create a new configuration file or edit an existing one.
- To easily create a new configuration file, you can use the Content Completion Configuration document template that is included in Oxygen XML Editor ( ). The document template includes details about how each element and attribute is used in the configuration file.
- If a configuration file (cc_config.xml) already exists for the particular document type (in the resources folder), you can modify this existing file.
-
If you extend a framework, you need to copy the content of the cc_config.xml file from the base framework and modify it (e.g. create a resources folder in your framework extension folder and place the file there). You also need to make sure that the folder that contains the cc_config.xml file in your extension (e.g. resources) is listed in the Classpath tab before the one from the base framework.
If you only want to make small changes or add extra rules in your custom content completion configuration file, you need to name it cc_config_ext.xml and all the rules inside it are merged with the base cc_config.xml file. The merging is done by taking all the rules specified in the cc_config_ext.xml file into consideration after processing the set of rules from the base cc_config.xml file.
- Make the appropriate changes to your custom configuration file.
- Save the file in the resources folder for the particular document type, using the fixed name: cc_config.xml (for example, OXYGEN_INSTALL_DIR/frameworks/dita/resources/cc_config.xml).
- Restart the application and open an XML document. In the Content Completion
Assistant you should see your customizations.Tip: In some cases, you can simply use the
Refresh (F5) action to test your customizations, without having to restart the application.
Attention: In the Classpath tab, if you have references to multiple resources folders, each with its own cc_config.xml file, the first reference listed in the Classpath tab takes precedence and the multiple configuration files are not combined.
Configuring Proposed Values
valueProposals
instructions that will match an element or attribute name
and has the following attributes:- path - A path within the document that matches the element or attribute that will have its content completion proposals changed. For example:You can use simplified forms of XPath in this attribute.
path="title"
matches all the<title>
elements in the document.path="chapter/title"
matches only the<title>
elements that are direct children of the<chapter>
element.path="@xml:lang"
matches all the@xml:lang
attributes in the document.path="title/@xml:lang"
matches only the@xml:lang
attributes that appear on<title>
elements.
The XPath expressions can accept multiple attribute conditions and inside each condition you can use AND/OR boolean operators and parentheses to override the priority.
You can use one or more of the following attribute conditions (default attribute values are not taken into account):- element[@attr] - Matches all instances of the specified element that include the specified attribute.
- element[not(@attr)] - Matches all instances of the specified element that do not include the specified attribute.
- element[@attr = "value"] - Matches all instances of the specified element that include the specified attribute with the given value.
- element[@attr != "value"] - Matches all instances of the specified element that include the specified attribute and its value is different than the one given.
Example: The following are examples of how you could use multiple boolean operators and parentheses inside an attribute condition:*[@a and @b or @c and @d] *[@a and (@b or @c) and @d]
The following are just examples of how simplified XPath expressions might look like:- elementName
- //elementName
- /elementName1/elementName2/elementName3
- //xs:localName
- //xs:documentation[@lang="en"]
Note: Using a namespace prefix requires that you declare it on the<elementProposals>
element or on an ancestor element. For example:<elementProposals xmlns:db5="http://docbook.org/ns/docbook" path="db5:listitem" insertElements="db5:para" />
- editable - Specifies the editable state of the attribute values, as reflected
in the Attributes view and the In-place Attributes Editor. The possible values for
the
@editable
attribute are:- true - The attribute values can be edited by choosing from a combo box or manually providing a value.
- false - The attribute values cannot be edited.
- onlyAllowedItems - The attribute values can be edited, but only by choosing from a list of proposed values, in a non-editable combo box.
<valueProposals>
element through: - One or more
<item>
elements, which are grouped inside an<items>
element.Tip: The<item>
element can have a@listValue
attribute, which can be set to true if you want those items to be part of a list attribute value (such asattr="item1 item2"
). - An
<xslt>
element that references an XSLT script that gets executed and must return an<items>
element.
<items>
or <xslt>
elements are specified with the help of the @action
attribute, which can
have any of the following values:- append - Adds new values to appear in the proposals list (default value).
- addIfEmpty - Adds new values to the proposals list only if no other values are contributed by the schema.
- replace - Replaces the values contributed by the schema with new values to appear in the proposals list.
The values in the configuration file can be specified either directly or
by calling an external XSLT file that will extract data from an external source. An
<xslt>
element must be used in this situation.
valueProposals
offers more flexibility compared
to the old match
element that was marked as
deprecated.<match elementName="lg" elementNS="http://www.oxygenxml.com/ns/samples"> <items action="replace"> <item value="stanza"/> <item value="refrain"/> </items> </match>
Other Important Notes About the Configuration File
- This configuration file only affects the content completion assistance, not validation.
- To test the effects of your changes, you should Refresh the source document.
Example: Specifying Values Directly
If you want to specify the values directly, the configuration file should look like this:
<!-- Replaces the values for an element with the local name "lg", from the given namespace --> <valueProposals path="x:lg" xmlns:x="http://www.oxygenxml.com/ns/samples"> <items action="replace"> <item value="stanza"/> <item value="refrain"/> </items> </valueProposals> <!-- Adds two values for an attribute "type", from no namespace --> <valueProposals path="@type" editable="onlyAllowedItems"> <items> <item value="stanza"/> <item value="refrain"/> </items> </valueProposals>
Example: Using Attribute Conditions
The possible values of an attribute depend on the value of another attribute from the same element:
<valueProposals path="property[@name='color']"> <items> <item value="red"/> <item value="blue"/> </items> </valueProposals> <valueProposals path="property[@name='shape']"> <items> <item value="rectangle"/> <item value="square"/> </items> </valueProposals>
Example: Calling an External XSLT Script
If you want to collect values from an external XSLT script, the configuration file should include something like this:
<xslt href="../xsl/get_values_from_db.xsl" useCache="false" action="replace"/>
get_values_from_db.xsl
is executed
to extract values from a database.xsl:message
as a debugging mechanism. These messages are presented in
the results area at the bottom of the application whenever the Content Completion
Assistant is invoked.@useCache
is set to false, then the XSLT will be invoked
any time the proposals are needed. If @useCache
is set to
true, then the XSLT is executed once and the obtained proposals are kept in
a cache and returned every time the proposals are requested again. You can use the
![](../img/Validate16.png)
Configuring Proposed Values in the Context Where the Content Completion was Invoked
A more complex scenario is if you want to choose the possible values to propose, depending on the context of the element where the content completion was invoked.
Suppose that you want to propose certain possible values for one property (for example, color) and other values for another property (for example, shape). If the property represents a color, then the values should represent applicable colors, while if the property represents a shape, then the values should represent applicable shapes. See the following code snippets:
<sampleArticle> <!-- The possible values for @value should be "red" and "blue" --> <property name="color" value=""/> <!-- The possible values for @value should be "square" and "rectangle" --> <property name="shape" value=""/> </sampleArticle>The content completion configuration file:
<config xmlns="http://www.oxygenxml.com/ns/ccfilter/config"> <valueProposals path="property/@value"> <xslt href="get_values.xsl" useCache="false" action="replace"/> </valueProposals> </config>The stylesheet that defines the possible values based on the context of the property on which the content completion was invoked:
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:xs="http://www.w3.org/2001/XMLSchema" exclude-result-prefixes="xs" version="3.0"> <xsl:param name="documentSystemID" as="xs:string"></xsl:param> <xsl:param name="contextElementXPathExpression" as="xs:string"></xsl:param> <xsl:template name="start"> <xsl:apply-templates select="doc($documentSystemID)"/> </xsl:template> <xsl:template match="/"> <xsl:variable name="propertyElement" as="element()"> <xsl:evaluate xpath="$contextElementXPathExpression" context-item="./*"/> </xsl:variable> <items> <xsl:if test="$propertyElement/@name = 'color'"> <item value='red'/> <item value='blue'/> </xsl:if> <xsl:if test="$propertyElement/@name = 'shape'"> <item value='rectangle'/> <item value='square'/> </xsl:if> </items> </xsl:template> </xsl:stylesheet>
The contextElementXPathExpression
parameter will be bound to an XPath
expression that identifies the element in the context where the content completion was
invoked.