Assigning queries

A query defines what data is extracted from the data source and takes the form of a path in the data source schema. You can assign a query to a template element to define the data context for that element and its children.

About this task

Queries in IBM® Rational® DOORS® start with the root element (module), continues with its child element (Object), then with the child attribute of the object. For example, Module/Object/Attribute/Name.

Queries in IBM Rational Tau have a syntax similar to the XPath syntax. However, unlike XPath, the Rational Publishing Engine query does not specify a filter; the filter and sort clauses are separate from the query. Each schema element, except the query, is defined through a Rational Tau native query. This query, which is expressed in OCL, fetches Rational Tau data. For example, the root element under the model element model.rootResource has the GetModelRoots() Rational Tau query attached to it.

Procedure

  1. Assign queries.
    1. In Document Studio, open the Data Source Schema view.
    2. Add elements to the template.
    3. Drag the queries from the Data Source Schema view into the elements.
    A query is assigned to a template element, you can use the attributes of the query type, the element dragged from the Data Source Schema view, anywhere in the template element and its child elements.
  2. Set a limit to the query element.
    Note: In IBM Rational Publishing Engine 1.1.1.1 and later, you can process a subset of template elements by setting a limit to the query elements.
    1. In Document Studio, select the template element that contains the query.
    2. In the Properties view, expand Data > Limit.
    3. Enter the number of objects from the data source to be used in the respective query. A value of 0 (zero) represents no limit set for the query.
  3. Assign recurrent properties to the queries. You use data recursion to extract all of the child requirements from a main source requirement in a schema.
    1. Select the element that contains the query.
    2. In the Properties view, for the Recursive Level property, enter how many levels deep the query is.
    3. For the Recursive Segments property, enter how many times the segments repeat in the query.
    See the example below about recursive levels and recursive segments.
  4. Save your changes.

Example: Recursive level and recursive segments

You can see a list of software requirements by using the PRRequirement query in the IBM Rational RequisitePro® schema available to you in the samples installed with Rational Publishing Engine: %RPE_HOME%\source\XML\examples\RequisitePro.xsd

For each PRRequirement, you can extract all of the child requirements, and for each child requirement, extract its child requirements without adding each query to your template.

Instead of adding each of these following queries:
  • [$1] Project/Requirements/PRRequirement to extract the PRRequirements.
  • [$2] $1/Children/Relationship/RelatedReq to extract child requirements of each PRRequirement.
  • [$3] $2/Children/Relationship/RelatedReq to extract child requirements of each child requirement of each PRRequirement.
You can construct one query for these requirements automatically:
  1. Add the Project/Requirements/PRRequirement/Children/Relationship/RelatedReq query to an element.
  2. Add values to the Recursive Level and Recursive Segments properties:
    • For the Recursive Level property, enter 4.

      Recursive Level represents how many levels deep the query is.

    • For the Recursive Segments property, enter 3.

      Recursive Segments represents how many times the segments repeat in the query. The segments in this example are Children/Relationship/RelatedReq.

On running the report, these queries are included:
  • [$1] – Project/Requirements/PRRequirement/Children/Relationship/RelatedReq
    Note: The first query must include the full context for the query.
  • [$2] – $1/ Children/Relationship/RelatedReq
  • [$3] - $2/Children/Relationship/RelatedReq
  • [$4] – $3/Children/Relationship/RelatedReq

Feedback