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.
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.
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.
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.
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
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: |
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: |
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: |
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: |
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).
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:
[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]
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).
Is this scheme valid according to CGM:1999? Yes, here's why.
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 Objectives
This clause provides rules for defining valid profiles of ISO/IEC 8632 [...]
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 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 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 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 Profile rules, proforma, and model profile
9.5.1 Overview
[...]
All CGM profiles shall include a completed PPF.