Minutes of CGM Open Meeting
Web Profile Technical Meeting

1. Introduction

This meeting was a continuation of the CGM Open meeting of the previous day, 3/10/98. The time was devoted entirely to technical topics relating to the Web profile.

2. Attendance

See "CGM Open Minutes for 1998-03-10". Separate attendance was not taken this day.

3. Proceedings

3.1 Agenda

We decided to attempt at this meeting to:

• Review Requirements document of W3C, "Use of CGM as a Scalable Graphics Format" ([Reqt]), as well as the issues raised in "Report of W3C and CGM Open Meeting on a Web Profile of CGM" ([Rpt]).
• Generate a position document from CGM Open to W3C.

Per the schedule constraints below, CGM open should submit these to W3C, as well as element-by-element suggestions about profile content.

3.2 Schedule

In discussion with Roy Platon (W3C editor for the Web Profile), we determined that 1^st June is a realistic deadline to begin first W3C review of a draft profile. This should ensure completion of the review and voting process by the end of 1998.
Roy is already working on the baseline document - ATA 2.4 specs in the form of the final CGM Amd.1 PPF for profile writers.
CGM Open should have detailed comments on the requirements and suggestions for profile features (in the form of editing instructions against the starting point, the ATA 2.4 Grexchange profile) to W3C by 1^st May, approximately.

3.3 "Goodness" Requirements

The first half-dozen requirements are more of the nature of "selling points" for CGM as a Web vector format, as opposed to technical requirements. There was relatively little discussion. The points which were brought up for sending to W3C are:

1. An additonal attribute of CGM is: test suites and certification services are available.
2. The "Lack of subset problems" could (as implied by the elaboration of the item) be changed to "Good Interoperability Potential".

3.4 Technical Requirements

Significant discussion happened around the technical requirements, roughly from "Vector Graphics elements" onward in the W3C list.

1. There was some discussion whether the separation of "Vector Graphics Elements" and "Curved Elements" is significant. The first is seen to be the endorsement of CGM because it is not raster, but rather scalable vector. The second, richness in curved drawing primitives, offers significant compression possibilities, as well as "preservation of objects" potential.
2. "Text and Font Selection". The key point is that CGM does contain the text elements, with adequate richness, rather than requiring simulations with lines, polygons, rasters, etc.
3. "Layering, stenciling/masking". It was agreed that this needs significant clarification.
   • It is now understood from previous discussions with W3C that stenciling/masking refers to the capability available through Closed Figure.
   • The "layering" requirement seemed clear enough in the January 1998 meeting between CGM Open and W3C - a simple layering mechanism in the style of CAD packages. However this interpretation was not immediately acceptable to all meeting attendees. Accordingly: we should seek clarification of W3C meaning here; and, any who dissent from a simple CAD layering model should prepare position papers and counter-proposals.
4. "Levels of Detail" was not well understood in the vector context. However the item is considered "deferrable" by W3C, and CGM Open agrees that it should be postponed until a subsequent revision of the Web Profile..
5. During discussion of "Include Raster Data", it was noted that it would be useful to register the new PNG compression technique(s) with SC24, for Tile Array usage. There was some discussion also of the Web requirements for raster size, esp. compared to ATA requirements (11"x17" drawings at 600DPI).
6. "Zoom and Pan". Again, the statement of the requirement could be clarified. The "not absolute dimensions" comment was not understood. The ATA profile allows only the'metric'mode, which ensures all pictures have dimension, and prohibits the dimensionless'abstract'mode. There was some discussion of the issue of prescribing default viewer behavior on pictures which are too big for their display viewport (scale-to-fit, or display part at proper scale?).
7. "Pick Single Elements". It is thought that Application Structures are a better way to handle picking, rather than Segments. This led to a discussion that instantiation is possible with Segments, but not with APS. Is instantiation of objects a requirement? Can it be satisfied with Symbols? There is a lot of bias against segments, but CGM Open is not willing to toss them yet, before seeing if they might have a role in instantiation of objects.
8. "Switchable Layers". See #3 above.
9. "Active Menus on Pick". Led to a long discussion of scripts and how to describe in the file format what an interpreter is to do upon selection of an object. It was agreed that additional ApsAttr types (or data within the'linkURL'ApsAttr type), such as'Link Description'would be useful to interpreters in multi-link situations. Also a'Screen Tip'ApsAttr type should be added. More careful requirements discussion is needed.
10. "Element Grouping into Semantic Structure". The scope of the item is not understood. Does it only mean that arbitrary, user-defined APS will be allowed, which can perform grouping and assign whatever application semantics are appropriate? Or does W3C have in mind some specific set of semantic groups which it wishes to encode in a standard way?
11. Links (internal, external) and Extractable Metadata. There was some discussion of useful APS and ApsAttr elements, but we did not fully address these requirements as listed in the W3C document ([Reqt]).
    There was not time to fully explore and resolve all of these issues. There was also insufficient time to pursue an element-by-element look at the ATA profile, and what should be changed for the Web Profile. CGM Open will meet again in about a month to pursue these to some sort of completion.

3.5 Other

We had some discussions of efficiency/compression. SVF (with relative coordinates) can achieve something like a 50% compression over CGM on the same pictures, according to Dave Rahnis of Bentley. This argues for the importance of the higher curved primitives (which SVF lacks). Is there also suggestion of adding relative addressing to all CGM encodings (Character has it now)?
We discussed and agreed to post the current 95 CGM:1992 Corrigenda (SC24-resolved CGM:1992 Defect Resolutions) on the Web site. They will be made accessible to those who inquire, but will not be "featured".

4. Next Meetings & Action Items

4.1 Next Meetings

There will be a 1-day technical working meeting on Friday, 17th April, to complete the technical issues review and prepare a contribution to W3C. The proposed venue is Chicago, and Lofton Henderson will investigate the Inso facilities in downtown Chicago. Expected attendance is 6-10 (note: Inso facilities subsequently approved, separate meeting notice to be circulated).
In order to maximize productivity during this short meeting, it is agreed that position papers should be prepared, and no new proposals may be brought up unless the positions have been circulated in advance of the meeting. This is the way that ISO works, and it is considered effective.
We also agreed that the technical requirements in [Reqt] and the technical resolutions in [Rpt] would be taken as defining the baseline, strawman Web Profile requirements and content, and position papers or proposals should take off from (and address) that baseline: changes, additions, deletions, endorsements, etc.
The possibility was discussed to meet in the vicinity of Paris in mid-May, around the time of SGML/XML Europe. Many CGM Open principals, as well as W3C people, will be present. We agreed to discuss this with W3C, and determine first what is the best way to work together and progress the Web Profile.

4.2 Action Items

Summary of action items from the meeting:

1. Henderson -try to arrange 4/17 meeting at Inso Chicago.
2. Henderson -contact W3C how to work together and move forward after Chicago meeting.
3. Weidenbrück -put the CGM:1992 "Corrigenda" on the Web site.
4. Gebhardt -summarize technical issues from this meeting's review.
5. All Prospective Chicago Attendees -read base documents if you are going to attend Chicago meeting; prepare position papers and circulate if you wish to make proposals at Chicago meeting regarding content of Web Profile.