Cascading CGM profiles -- why, what & how

Author:
Lofton Henderson
Date of this version:
20 March 2005

Status of this document

All of the major concepts of the cascading profile method of profile definition, as well as the justification based on the rules of ISO CGM:1999, are defined in this version. The WebCGM TC has given general approval of the contents of this document. There remain a few minor pieces to be completed, such as some more examples. In addition, there are some issues of details that have not yet been definitively resolved. These affect only the details of exactly how to implement a cascading profile, and not the concept or overall methodology.


Table of Contents


References


Introduction

At the recent CGM Open WebCGM Technical Committee (TC) in Cologne [6], the TC unanimously concluded that:

This is based on the concept of cascading profiles, which will be explained in this document.

There are numerous details of about implementation of cascading profles that are still being worked out. These will be identified and explored here. But these details (issues) should not confuse the overall conclusion to migrate to cascading profiles, for the benefit of the technical graphics application community.

Summary of recommendations

At this stage of consensus and issue resolution, the TC has one governing recommendation of principle, and two specific recommendations.

Recommendation 1: Similar but slightly different technical graphics profiles should all be defined as direct or indirect derivatives of the generic Web technical graphics profile WebCGM [2].

This recommendation would be applicable (at least) to ATA GREXCHANGE and AECMA S1000D, as well as to less active technical graphics profiles such as CALS MIL-STD-28003B, J2008, and RIF.

Recommendation 2: ATA GREXCHANGE 2.9 for V1,2,3 CGM (sec-7.2 of [3]) should be replaced by a derived profile based on, specifically, WebCGM 1.0 Rev.2 [2].

Recommendation 3: ATA GREXCHANGE 2.9 for V4 CGM (sec-7.3 of [3]) should be replaced by a derived profile based on, specifically, either ATA GREXCHANGE 2.9 for V1,2,3 CGM, or WebCGM 1.0 Rev.2 [2].

Which of the "either...or" is an issue to be resolved.

Recommendation 4: The current AECMA S1000D should be replaced by a derived profile based on, specifically, WebCGM 1.0 Rev.2 [2].

A future version might be based on ATA GREXCHANGE, contingent upon the resolution of issues identified below.

The multiple profiles problem

Multiple similar but different profiles

There are a number of similar but slightly different CGM profiles in the technical graphics arena: WebCGM, ATA, AECMA, etc. Some small divergences are well-founded in requirements for the various arenas. However, there are a couple of problems:

All parties agree that maximum similarity is a desirable goal, with only a few, well-justified differences that are clearly highlighted and easily understood.

Current profiles' definitions

CGM:1999 rules for profiles say that a valid profile is defined in a Profile Pro-Forma (PPF), nominally by reference to the Model Profile (MP). The PPF is a huge table (or set of tables) with about 200 rows -- one for each CGM element or composite functionality -- and three columns -- Element, new profile, and Model Profile (reference). See Annex I of CGM:1999.

The ATA Grexchange profile is a complete PPF, with a most rows identical to the MP ("as Model Profile"), and a relative handful of difference rows. The differences tend to get lost in the several score pages of the PPF.

The AECMA S1000D profile is defined by a reference to the ATA profile. It presents only the handful of differences between it and the ATA profile, instead of the complete PPF. There is a problem in that it isn't tied to a specific version of the ATA profile

Cascading profiles to the rescue

The concept

At OASIS CGMO WebCGM TC meeting [6], it was agreed that WebCGM -- a "generic" technical graphics (TG) profile for the Web -- provides a good foundation from which to define other TG profiles such as ATA and AECMA. Further, ATA is a good foundation for AECMA.

WebCGM is defined by a full PPF, relative to the Model Profile.

Example 1. A snippet of WebCGM full PPF looks like this:

Element Specifications - WebCGM Specifications - Model Profile
T.19.23 Same as Model Profile  No  

PARABOLIC ARC

[v3]

References:

7.6.23
T.14.2
D.2.2.1

Element is: Required No; Permitted No; Prohibited Yes;

Zero-length geometric degeneracies shall be as defined in T.14.2.

Other: None.

Element is: Required No; Permitted Yes; Prohibited No

Zero-length geometric degeneracies shall be as defined in T.14.2

Other: None.

T.19.24 Same as Model Profile  No  

NON-UNIFORM

B-SPLINE

[v3]

References:

7.6.24
T.14.2
D.2.2.1

Element is: Required No; Permitted No; Prohibited Yes;

Set of spline orders:

Maximum number of control points:

Zero-length geometric degeneracies shall be as defined in T.14.2.

Other: None.

Element is: Required No Permitted Yes Prohibited No

Set of spline orders: cubic spline (order=4).

Maximum number of control points: 4096.

Zero-length geometric degeneracies shall be as defined in T.14.2.

Other: The spline shall be clamped form, i.e., the first 4 knots shall be identical and the last 4 knots shall be identical.

This snippet shows that WebCGM prohibits the elements PARABOLIC ARC and NON-UNIFORM B-SPLINE, whereas Model Profile permits them.

If ATA were defined by a "delta PPF" from WebCGM, it would both clarify the differences and discourage arbitrary or accidental differences. A "delta PPF" would contain:

Example 2. A snippet of such an ATA delta-PPF definition, derived from the WebCGM base profile, might look like this:

Element Specifications - ATA Grex 2.9 Specifications - WebCGM
T.19.23 Same as WebCGM  No  
PARABOLIC ARC

[v3]

References:

7.6.23
T.14.2
D.2.2.1

Element is: Required No; Permitted Yes; Prohibited No;

Zero-length geometric degeneracies shall be as defined in T.14.2.

Other: None.

(Note: same as Model Profile.)

Element is: Required No; Permitted No; Prohibited Yes

Zero-length geometric degeneracies shall be as defined in T.14.2

Other: None.

T.19.24 Same as WebCGM  No  
NON-UNIFORM

B-SPLINE

[v3]

References:

7.6.24
T.14.2
D.2.2.1

Element is: Required No; Permitted Yes; Prohibited No;

Set of spline orders: cubic spline (order=4).

Maximum number of control points: 4096.

Zero-length geometric degeneracies shall be as defined in T.14.2.

Other: The spline shall be clamped form, i.e., the first 4 knots shall be identical and the last 4 knots shall be identical.

(Note: same as Model Profile.)

Element is: Required No Permitted No Prohibited YesSet of spline orders:

Maximum number of control points:

Zero-length geometric degeneracies shall be as defined in T.14.2.

Other: None.

This snippet shows that ATA Grex 2.9 allows the PARABOLIC ARC and NON-UNIFORM B-SPLINE elements, whereas WebCGM does not, and it includes limits and constraints that are basically the same as those in the Model Profile. It includes a helpful informative note to that effect.

AECMA could be defined by a delta PPF from ATA (pending resolution of the free-access issue below). AECMA's delta PPF would contain:

Issue ata-available: The first-bullet rule above effectively prevents the ATA profile from being the base profile in this cascade. (I.e., it costs several thousand dollars to get a CD, and the CGM profile is not on the Web.)

Example 3. A snippet of such an AECMA definition, derived from an appropriate ATA base profile, might look like this:

[TBD. Finish AECMA example, of a couple PPF rows here, boxed like this.]

Caveat. Until resolution of the open-availability issue, it is recommended that the AECMA S1000D profile be defined as a delta PPF against WebCGM, not against ATA. In other words, S1000D should look like example 2 above, not example 3. I.e., copy the delta PPF of the ATA profile, and edit any changes appropriate for S1000D.

Thus, the profiles would be defined in a cascading sequence:

By following links back through the cascade, it is possible to discover the value of any item in any profile. Furthermore, if the PPF markup grammar (assuming XHTML for the PPF) were to be regularized, it would be possible to make a simple process that constructs a full PPF for any profile along the cascade.

Issue delta-full: Should both the delta PPF and a full PPF be made available? (Comment. If AECMA's differences from ATA are not a subset of ATA's differences from WebCGM, then AECMA cannot find some of its difference rows in ATA's delta PPF -- see implementation section.)

Issue which-normative: If yes, then which one should be normative?

Issue webcgm-delta: A peripheral issue is whether WebCGM itself (1st bullet in above cascade) ought to be defined by delta-PPF from MP, instead of full PPF. Since MP is not really an implementation target, the full PPF makes sense here (more convenient for implementors).

Implementation of cascading profiles

Note. To facilitate WebCGM-based cascading profiles, CGMO will cut-paste XHTML copy of the WebCGM 1.0 2nd release PPF to the CGMO WebCGM TC Web site. It will also back-link to a preserved dated copy of the WebCGM 1.0 1st release. And the WebCGM 2.0 PPF, when available, should move to the head of the chain and back-link to WebCGM 1.0 2nd release PPF.

Actually, this detail is related to the "delta-full" issue above -- What to provide so that the process of writing a cascading profile based on WebCGM is easier and less likely to incur transcription errors.

Process:

  1. Include the URL pointing to of your base profile.
  2. Start with the provided delta-PPF template [LH to provide one].
  3. For each element/functionality where your profile differs from base profile,

    [TBD...break this down by subcases: new profile differs from base profile and base (delta) PPF contains the row; new profile differs from base profile and base (delta) PPF does NOT contain the row]

  4. Add text subsections after your delta PPF, for any differences from Base Profile which are not expressible in the PPF. (Yes? or do we want to discourage this?)

An XHTML document, "Delta Profile Template", will be provided [LH todo], containing a skeleton document for a delta profile. It will include a delta PPF template (table).

Justification in CGM:1999

Is this scheme valid according to CGM:1999? Yes, here's why.

  1. the imperative of subclause 9.3.1, item #2, that similar profiles shall be defined as derivatives, and shall not duplicate lots of similar stuff.
  2. interpretation of subclause 9.5.1, "shall include a completed PPF", as follows:

    then the derived profile contains "a completed PPF".

As can be seen, the validity argument hinges on reasonable interpretation of the somewhat ambiguous phrase "a completed PPF". #2 is such a reasonable interpretation, and very much in keeping with the spirit of CGM:1999 clause 9 ("Rules for profiles). Every PPF row is available either directly in the document, or by following a link to another PPF in another document.

It will also be noted that interpretation #2 is recursive -- the base profile may itself be derived and partly defined by a link to its base, ...etc. But at the end of the chain, there must be a full, all-rows PPF.

===== 9.1.1 =====

9.1.1 Objectives

This clause provides rules for defining valid profiles of ISO/IEC 8632 [...]

===== 9.1.4 =====

9.1.4 Purpose of the Model Profile

[...]

2. It is a guide to writing profiles. As an instance of a profile, the Model Profile is a starting point from which an application-specific profile should be defined, for those application communities for which the Model Profile itself does not suffice. Writers of profiles should consider each of the specifications of the Model Profile and either accept the specifications where they are adequate, or modify them when not.

[Ed. note: "should", not "must" or "shall"]

===== 9.2.1 =====

9.2.1 Conformance of profiles

A profile of ISO/IEC 8632

[...]

2. shall be structured in accordance with the structural components and presentation rules defined in 9.4;

[...]

===== 9.3.1 =====

9.3.1 Criteria on the profile in its entirety

The following criteria shall be applied to a proposed profile.

[.....]

2. The functional purpose of a proposed profile shall not be satisfied by an existing profile. If the functional purpose of a proposed profile can be satisfied by a derivative of an existing profile, it shall be so defined - significant subsets shall not be replicated.

===== 9.4 =====

9.4 Form and format of a profile

A profile of ISO/IEC 8632 shall contain the following components:

[...]

5. specification of the set of elements, parameters, implementation requirements, and features of ISO/IEC 8632, presented in the format and according to the rules of 9.5.

[...]

===== 9.5 =====

9.5 Profile rules, proforma, and model profile

9.5.1 Overview

[...]

All CGM profiles shall include a completed PPF.



Change history