Cascading CGM profiles -- why, what & how

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

• Introduction
• Summary of recommendations
• The multiple profiles problem
  • Multiple similar but slightly different profiles
  • Current profiles' definitions
• Cascading profiles to the rescue
  • The concept
  • Implementation of cascading profiles
• Justification in CGM:1999
• Change history

References

• [1] ISO CGM:1999 part 1 (ISO/IEC 8632-1:1999): available at http://isotc.iso.ch/livelink/livelink/fetch/2000/2489/Ittf_Home/PubliclyAvailableStandards.htm
• [2] WebCGM 1.0 Rev.2: http://www.w3.org/TR/2001/REC-WebCGM-20011217/
• [3] ATA GREXCHANGE(r2.9) for V1,2,3 CGM: not publicly available.
• [4] ATA GREXCHANGE (r2.9) for V4 CGM: not publicly available.
• [5] AECMA S1000D CGM profile: @@@link needed@@@
• [6] CGMO WebCGM TC minutes: http://lists.oasis-open.org/archives/cgmo-webcgm/200406/msg00008.html

Introduction

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

• similar but slightly different technical graphics profiles, such as ATA GREXCHANGE and AECMA S1000D, should all be defined as direct or indirect derivatives of the generic Web technical graphics profile WebCGM [2].

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:

• despite intentions that they should be as similar as possible, there is a tendency for them to diverge unintentionally, e.g., ATA and WebCGM have diverged lately, after initial convergence.
• ambiguous definition, e.g., AECMA is defined by reference to ATA, but the exact base ATA profile is somewhat ambiguous.

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:

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:

• an unambiguous URL reference to the defining text of a specific version of the "base profile", in this case WebCGM.
• a PPF containing only those rows of the full PPF where ATA differs from WebCGM
• the ATA values in the "new profile" (2nd) column, and the WebCGM values instead of the Model Profile values in the reference (3rd) column.

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

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:

• an unambiguous URL reference to the defining text of a specific version of the "base profile", in this case ATA.
• a PPF containing only those rows of the full PPF where AECMA differs from ATA
• the AECMA values in the "new profile" (2nd) column, and the ATA values (instead of the Model Profile values or WebCGM values) in the reference (3rd) column.

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:

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:

• WebCGM is defined by reference to MP (in a full PPF)
  • ATA is defined by delta-PPF reference to WebCGM (delta PPF).
    • AECMA is defined by delta-PPF reference to ATA (delta PPF).

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,
   • ensure proper CGM:1999 PPF reference in 1st column;
   • put reference profile (Base Profile) stuff in 3rd column;
   • put your new-profile stuff in 2nd column.

   [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:
   • if the derived profile contains a URI reference to another (base) profile,
   • and if the latter is publicly accessible,
   • and if the derived profile contains "delta differences" in PPF format,
   • and if the sum of the definitions (derived + base) covers all PPF rows,

   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.

Change history

• 2005-03-20
  • The section "Justification in CGM:1999" finished.
• 2004-06-26
  • Incomplete draft version.