On 12 January 1998, representatives of W3C and CGM Open met in San Jose, CA, to discuss production of a Web profile for CGM. Lofton Henderson represented CGM Open, Bob Hopgood and Chris Lilley represented W3C.
2.1 Reason for the Meeting
Although the formation of CGM Open is not yet completed, nevertheless it is progressing, and a Web profile for CGM is already agreed to be a priority item on its agenda. Graphics experts associated with W3C have been working on the requirements and preliminary details of a Web profile for CGM for some time. All agree that a single Web profile is desirable.
2.2 Meeting Attendees
Lofton Henderson is a graphics specialist from Inso Corporation. Inso is a W3C member, but he participated in the meeting also as a representative of CGM Open.
Chris Lilley is the Font and Graphics Coordinator, W3C. His work on a Web profile and related topics is funded by the European Commission as a part of "W3C-LA" (W3C Leveraging Action), an effort to build Demonstrators on top of W3C's basic standards. Amana, a W3C Reference Browser, is being built as a part of this effort.
Bob Hopgood is Associate Director, Department of Computation and Information at Rutherford Appleton Laboratories (RAL). He is the RAL member on the W3C Advisory Committee.
The ultimate goal is a common Web profile for the two groups, to the greatest extent possible. For W3C, the goal is a profile which would become a W3C Recommendation. For CGM Open, the goal is an effective profile for use of CGM in Web applications by consortium members (and others).
For this meeting, the goal was a careful review of technical topics of both parties, exploration of how to collaborate, discussion of the respective roles of the two parties, and agreement on a way forward and next steps.
2.4 About CGM Open
Henderson discussed the motivation, goals, and status of CGM Open. These details can be found on the CGM Open Web site - www.cgmopen.org - in both initial meeting minutes and the public announcement of intention to form the consortium.
More recently (December 1997), a Drafting Committee met at the SGML/XML '97 conference in Washington, DC, and agreed on draft foundation documents (Charter, Bylaws) for review, revision, and adoption. At this same meeting, there was liaison with officers of SGML Open, which has resulted in mutual interest in some close relationship between the consortia, and possible sharing of infrastructure.
2.5 Review of Existing Profiles
Henderson presented the history and status of current major profiles, and the attendees spent some time discussing relevance to the Web profile. Briefly:
1. CALS, CALS/A. Serious use of CGM in electronic document specifications started with CALS, and these were in fact the first profiles of CGM. In has been known since 1992 that a Revision B (CALS/B) is needed. The task of producing CALS/B was awarded to a contractor with no previous competence in CGM and profiles. After 3 years, the work is incomplete and currently unfunded. "CALS is dead" seems an accurate characterization.
2. ATA. ATA started with the CALS profiles several years ago, and has forged ahead with a continuous development and maintenance effort. For several years, the ATA profiles have been based on the pro-forma and Model Profile of CGM Amendment 1 (1994), "Rules for Profiles". ATA has two profiles: GRexchange is mostly a Version 3 profile with the single Version 4 extension of an Application Structure of type 'grobject' (APS), and an optional 'region' Application Structure Attribute (ApsAttr); and, IGexchange, which is a profile for intelligent graphics conforming to the specific ATA document graphical data model. IGexchange is a superset of GRexchange. Current release is 2.4. (Also reviewed was the history of some of the key technical issues for V4 profiles of CGM: embedded versus overlay object tagging models, and internal versus external location of intelligence.)
3. PIP. The Petroleum Industry Profile, aimed at an application constituency significantly different from technical electronic documents, was based on emerging Rules for Profiles (pre-PPF), and a rich core profile for advanced visualization applications (this was the model for the "APV" International Standardized Profile). Its principal purpose was to correct errors in and to accurately document the seismic extensions of CGM+.
4. J2008. Used by the automotive industry, J2008 has been following the CALS profile (CALS/A). At a recent J2008 meeting, it was recommended to switch to the ATA Grexchange profile as a basis. J2008 proposes to deal with the legacy (CALS/A) and existing applications issue by allowing (grandfathering) the use of 28003A for some period of time, while making clear that ATA Grexchange is preferred.
5. RIF. The railroad industry has adopted the ATA GRexchange profile as a part of the Electronic Parts Catalog Exchange Specification (EPCES).
2.6 Recent ATA Profile Developments
Recent ATA profile work was reviewed. The 2.4 release of the ATA profiles is pending (March?). This is mostly a minor maintenance release, but has one important addition to 2.3: simple object identification, without the implied full semantics of the IGexchange document model, has been added. This is intended to support applications (currently available from vendors) which want to use effectively the GRexchange profile, but with object tagging internal to the CGM, to enable association of external (to the metafile) intelligence.
W3C asked: what does this mean in interchange, what's a browser supposed to do with the 'grobject' APS? In GRexchange 2.4, no particular browser action is specified for the 'grobject' APS - intelligence is external to the picture and is the domain of the individual application. This is even an issue for full IGexchchange. While there is a full semantic model for the intelligent markup in the graphics, browser behavior specification is not part of the ATA 2100 standards suite presently.
3. Toward A Web Profile
After significant background discussion and review of the state of the art in CGM profiles, the rest of the meeting was spent on discussing a suitable Web Profile.
W3C has produced some significant baseline documents,
which should be reviewed as background to these topics.
3.2 Writing the Web Profile
All agreed that ATA GRexchange 2.4 is a good starting point.
As there are some deviations between the text of GRexchange and the actual official PPF (Profile Pro-Forma) of CGM Amd.1, W3C agreed that it would be useful to put the text of 2.4 onto Amd.1 PPF as a starting point. Funding to do this is available. Action. Henderson to get electronic form of Amd.1 PPF to W3C, plus GRexchange 2.4 electronic text, and finally to inquire of ATA about permission to use the latter.
Once this initial step is finished, then Web-profile specific changes will be applied. Such changes will be guided by the Web requirements specification and review.
A specific timeframe or schedule was not discussed.
3.3 The OBJECT Tag
[Ref1] describes the HTML OBJECT tag as the way to reference in-line CGMs in Web documents. Use of the PARAM element is recommended, with the set of specifiable attributes: SCALABLE, TRANSPARENT (see below), VIEWPORT, HALIGN, VALIGN. (See below for disposition of OPAQUENESS in [ref1] proposal).
3.4 Web Profile Graphical Requirements
"Use of CGM as a Scalable Graphics Format", is based on and contains analysis of CGM vis a' vis "W3C Scalable Graphics Requirements". The latter is a terse but complete specification which W3C has derived for the requirements of a Web vector format.
Some of the more significant specific graphical topics are discussed in the following sub-sections.
3.4.1 Color Models
While [ref1] seems to endorse the multiple color models of CGM (RGB, CIE flavors, CMYK, etc) and the Colour Calibration element, ATA 2.4 only allows RGB (except in JPEG compressed content). This issue was not discussed at the San Jose meeting.
W3C noted that the ATA profile is principally used for black-and-white technical illustration, whereas grayscale and color would have more importance in a Web profile.
The possibility was discussed of achieving the alpha-transparency requirement by registering RGB-alpha as a CGM Colour Model in SC24. The possibility of doing this for the W3C sRGB calibrated color scheme was also discussed, but it is agreed that non-calibrated RGB should also be available.
This has two aspects:
1. Optional transparent placement of an entire picture on existing material (effectively suppressing background color of the picture),
2. and, Alpha values for individual colors and elements.
The first is proposed to be handled by a parameter on the HTML OBJECT tag. The second could be handled by registering a RGB-alpha Colour Model with SC24. Note - while the first is fairly high priority, the priority of the second is apparently "deferrable".
3.4.3 Character Sets
Character Sets is one area where ATA and a Web profile appear to have truly different requirements. While the more limited technical community of ATA can work with ISO Latin 1 and Symbol in its graphics interchange, a Web profile which is a W3C Recommendation must align with the text specifications, and allow full Unicode. We need to research how to specify Unicode in Character Set List. Unicode characters are apparently required for both graphical String and non-graphical String Fixed data types.
[Ref1] notes the ATA "Core13" font set, as well as the 35 fonts of the "APV" International Standardized Profile (similar to PIP/II. No choice is made for the Core font set of the Web profile. Because of the Character Set requirements, the core set cannot always suffice. It is probably appropriate that the Web profile use a specification like ATA 2.4: any font outside of the core set shall be described with Font Properties.
The Web profile should also require the use of Restricted Text (always, for all fonts).
A layering mechanism would be useful. A simple modal scheme such as ATA's is probably sufficient as far as it goes (i.e., there is no need for something based on APS or segments). But it could be made more application-independent by such features as a Layer Description Table (descriptive strings associated with layers, which viewers could display to assist users in choosing amongst layer display and manipulation options of the viewer). Visibility of layers would be entirely a viewer functionality - as with ATA, a correct picture is obtained with all layers on (i.e., by viewers which ignored the layers).
This refers to the capability provided by Closed Figure. It is not a problem in a Version 3 profile.
3.4.7 Line Termination and Mitering
These are covered by the V3 Line Cap and Line Join (and Edge equivalents). There was some discussion about whether 'triangle' cap style should be included (it is unique to CGM and not commonly seen in other graphics systems and formats).
3.4.8 Level of Detail
It was decided that this could be deferred until after the initial Web Profile release.
3.4.9 Symbol Library
The explicit Symbol Library mechanism of ATA was discussed and appears to fit the Web requirements fairly well.
3.5 Hotspot/Hyperlink Definition
Linking from HTML to graphics, graphics to HTML, and graphics to graphics need to be supported. The HTML linking will be via the OBJECT tag.
For graphic-to-HTML and graphic-to-graphic linking, it was agreed to base the hotspot-hyperlink definition of the Web profile on the V4 extensions of GRexchange. The utility of the rich model of IGexchange is appreciated, for the specific application community of that profile, but it is not seen as applicable to a generalized hotspot-hyperlink mechanism for the Web.
3.5.2 Basic Definition
The V4 elements which may be used in the Web profile are:
1. 'grobject' APS of GRexchange 2.4, for identifying objects.
2. Optional 'region' ApsAttr of GRexchange 2.4 (for legacy graphics, and/or fast object selection and processing).
3. Optional 'LinkURL' ApsAttr, for giving the destination of a link from the object.
4. Optional 'ViewContext' ApsAttr, for guiding browsers in minimal useful display area around an object.
3.5.3 Link Addresses
It is required that graphics be addressable down to the picture and object, from links in either text or graphics. Addresses will be strings which follow the rules of URLs, including the shorthands which are possible for relative URLs. See "External Links" and "Referring to Pictures within a CGM" in [ref1].
W3C had proposed in [ref1] a syntax for addressing graphical objects which would work for addressing pictures in multi-picture metafiles, or objects within pictures, but didn't seem to efficiently cover objects in multi-picture metafiles.
The basic addressing approach is proposed to be that which is used in HTML files, a URL structured as: <metafile_name>#<extension>.
The second picture in a metafile example.cgm might be, for example: .../example.cgm#2. Or a given object might be: .../example.cgm#fillercap.
What is needed, and is still an Open Issue, is a syntax after the "#" for simultaneous picture and object selection. Nice defaulting in the very common case of 1-picture metafiles would be a bonus. This was agreed to be a detail we could work out during the development and review of the profile.
3.4.4 What's Hot and What's Not
We discussed whether there was any need for an ApsAttr which would indicate which objects were "hot" or pickable. An object could be only a destination of a link, or it could be a source of a link. It is probably only hot or selectable in the latter case. It was decided at least initially in this Web profile, that this could be implicit for browsers: if there is a 'LinkURL' within the 'object' APS, then the object is hot.
[Ref1] describes the need to be able to include or associate arbitrary metadata with the graphics. If it is to be included in the CGM, and if V4 syntax is to be used for this purpose, then we need to take a look at the ATA restriction which allows only the explicitly defined APS and ApsAttr types to be present in conforming metafiles.
[Ref1] does not address the topic, but it was mentioned in the meeting (with no clear conclusion): searching for text strings within graphics. If this is a requirement, then we should consider inclusion of the 'para' APS type and the 'content' ApsAttr from IGexchange.
4. Next Steps
1. As W3C has funding and resources for a document editor (Roy Platten of RAL), W3C will start drafting a Web profile by producing a baseline - GRexchange 2.4 on proper CGM Amd.1 PPF.
2. W3C will review the element-by-element GRexchange specifications against Web requirements, and modify the baseline of #1 for a draft Web Profile.
3. San Jose meeting participants will make a quick review to verify correct implementation of agreed functionality.
4. CGM Open will review the requirements identified and discussed in [ref1], discuss them before and at its next meeting (March), and generate consensus positions for modification, extension, etc, at or after that meeting.
5. CGM Open will review and comment on the draft profile produced by W3C, and will work with W3C to resolve differences and achieve a single consensus profile.
6. W3C will put out a Draft Recommendation.