Smart Restrictions

www.altova.com Print this Topic Previous Page Up One Level Next page

Home >  User Guide and Reference > Editing Views > Schema View >

Smart Restrictions

When restricting a complex type, parts of the content model of the base type are rewritten in the derived type. This can be confusing if the content model is complex because while editing the derived type it might be hard to correctly remember exactly what the content model of the base type looks like.

 

Smart Restrictions combine and correlate the two content models in the graphical view of the derived content model. In the derived complex type, all particles of the base complex type, and how they relate to the derived type, can be seen. Additionally, Smart Restrictions provide visual hints to show you all possible ways to restrict the base type. This makes it easy to correctly restrict the derived type.

 

 

To switch on Smart Restrictions:

Click the Smart Restrictions icon ic_smart_res. in the Schema Design toolbar.

 

 

The example that follows illustrates the features of Smart Restrictions.

 

The following complex type is the base type used in this example:

base_complexType

The complex type "derived" is derived from the "base" type as follows:

 

1.Create a new complex type in the schema and call it "derived".
2.In the Details Entry Helper select "base" from the base drop-down list and "restriction" from the derivedBy drop-down list.

derive_detailsEntHelper

With Smart Restrictions switched on, the new derived type looks like this:

derived_complexType

Notice the following controls that can be used to restrict the derived type in this example:

Use this icon ic_checkbox to remove elements that are in the base type from the derived type. Here, elem1 has been deleted. To add it again, click this icon ic_plussign.

derived_elem_deleted

Click the down arrow on the Choice compositor ic_down_arrow to get the following list, which allows you to change the Choice model group to a Sequence model group:

model_group_restriction

It is also possible to change wildcards in the same way, as seen in this example:

derived_wildcard

For a complete list of which particles can be replaced by which other particles, see the XML schema specification.

 

Change the number of occurrences of the model group using the following control ic_change_minoccur to increase the minimum number of occurrences by clicking the plus sign over the "1", or to decrease the maximum number of occurrences by clicking the minus sign under "4". These controls are shown if the occurrence range in the base describes a real range (e.g., 2-5) and not a certain amount (e.g. 4-4). They are also displayed if the occurrence range is wrong.

derived_change_minoccur

Here you can see that the minimum occurrence for this element has been changed to 2. Notice that the model group now has a blue background, which means that it is no longer the same as the model group in the base complex type. Also, the permitted occurrence range of the model group in the base particle is now displayed in parentheses.
It is possible to change the data types of attributes or elements if the new data type is a valid restriction of the base data type as defined in the XML schema specification. For example, you can change the data type of elem3 in the "derived" data type from decimal to integer. After you do this, the element has a blue background to show that is different from the element in the base type, and the type that the element has in the base type is displayed in parentheses:

 

derived_change_datatype

This example shows attributes whose data types have been restricted in the derived complex type:

derived_attrs

Smart Restrictions alert you to pointless occurrences in the content model. A pointless occurrence happens, for example, when a sequence that is present in the content model is unnecessary. This example shows a pointless occurrence:

pointless_occurrence

Please note: Pointless occurrences are only shown if the content model contains an error. It is possible for a content model to contain a pointless occurrence and be valid, in which case the pointless occurrence is not explicitly shown in order to avoid confusion.

 

See the XML schema specification for more information about pointless occurrences.

 


© 2019 Altova GmbH