CGM OPEN ACTIVITY REPORT -
2000 WASHINGTON DC TECHNICAL WORKING GROUP

Revision: 1.1

Date: January 22, 2000

Preface

This report describes activities of CGM Open Technical Committee meeting held on December 7, 2000 in at XML 2000 in Washington DC

Table of Contents

1 Meeting Details

1.1 Location and Dates

Washington DC, 7 December 2000

1.2 Meetings

• CGM Open Technical Committee 7 December 2000.

1.3 CGM Open Attendees

• Dave Cruikshank
• Dieter Weidenbruck
• Lofton Henderson
• Harry Whittaker
• Jeff Courtney
• Lynne Rosenthal
• Chris Lilley (Consulting)

2 Agenda

2.1 Technical Committee

The items on the agenda of the Technical Committee include:

• Number of pictures per file

• Continued APS

• Multiple linkuri

• Constitution of a hotspot

• Protection region element

• Character sets in non-graphical strings

• Plan to address issues

3 Output and Action Items

4 Activity Reports

4.1 Technical

Due to arising technical issues during vendor implementation, a technical meeting was scheduled to address them.

4.1.1 Number of pictures per file

Currently the WebCGM profile has no maximum on the number of pictures allowed in a CGM file, while many other profiles restrict the number of pictures to one. It was noted that the majority of applications dealing with CGM are only capable of handling one picture per metafile. It was decided that WebCGM should migrate towards limiting the number of pictures to one. Because of potential existing data, this issue may be deferred until WebCGM 2.0. A discussion will be opened on the CGM Open mailing list to determine a direction. The resolution is targeted for completion by Jan 20, 2001.

4.1.2 Continued APS

By using the same apsid multiple application structures may be combined into one logical application structure. This is a feature of the CGM standard and allowed in WebCGM. The issue that has arisen here is that there is no equivalent construct in XML, making it impossible to write a clean DOM implementation. It was pointed out that multiple application structures within the CGM file could be mapped logically to a single structure in the XML equivalent, but addressing one of those application structures would still be difficult. It was decided that, initially a discussion would be opened within the CGM Open membership, and would be expanded to the CGM Open mailing list at a later date.

4.1.3 Multiple linkuri

The WebCGM profile allows for multiple occurrences of the linkuri attribute to support "fat" links. With a linkuri attribute possibly being carried externally in an XML companion file, a problem arises. XML does not allow multiple occurrences of attributes to an element. Since the name attribute is also allowed multiple times, there could be an issue there, too.

Consulting with Chris Lilley, the group learned that SVG would implement multiple links by using an Xlink containing several locators.

This will probably address the linkuri issue, but not the name attribute problem. The requirement for multiple name attributes needs to be validated.

4.1.4 Constitution of a hotspot

The question of what is sufficient and necessary to make an application structure "hot". Everything that has an apsid should not necessarily be hot. If an application structure has a linkuri, it should obviously be hot, however if the linkuri is stored in companion data how does the application sense that. This will be resolved when we have a CGM DOM, but there needs to be an interim solution to address this. It was suggested that the existence of a null region would indicate that the object was not subject to a pick event, while the existence of a null linkuri would indicate that a linkuri exists in companion data. A null region would override a null linkuri. This change would require some wording changes in the WebCGM 1.0 specification. We will generate some discussion through the CGM Open membership list, followed by discussion among the CGM Open mailing list.

4.1.5 Protection region element

It was determined that the addition of support for the Protection region element is a WebCGM 2.0 action.

4.1.6 Character sets in non-graphical strings

There exists a conflict between characters allowed in non-graphical strings as it is stated in the profile and as it is stated in the definition of the fragment identifier in section 3.1.1. In the profile the character sets ISOlatin1 LHS, UTF-8, and UTF-16 are allowed. In section 3.1.1., the characters for the fragment identifier are limited to the lower and upper case alpha characters, the numeric digits, and the namesafe characters which includes "$", "-", "_", and "+". This restriction may not be a big issue with apsid, but in the case of the name attribute being used in a fragment address, it could cause problems. The limiting specification seems to be RFC 1738, which defines the character sets for linkurls. RFC 1738 does allow for some of the other RHS characters by using an escape sequence.

According to Chris Lilley, XML 1.0 allows a fairly rich subset of unicode. WebCGM should reference XML 1.0 in section 2.3 where "name form" is defined and further reference appendix B where the term "letter" term is defined. In order to fully us this feature, UTF-16 will have to be converted to UTF-8 and escaped according to RFC 1738. A decision was made that WebCGM 1.0 will be modified to reference what is said in XML 1.0 to satisfy this issue.

4.1.7 Plan to address issues

WebCGM 1.0 will be republished by W3C as a "Second Release", similar to XML 1.0 Second Edition. It is a maintenance and defect-correcting release, not a functional-enhancement release (work on the latter is in progress). It will be accompanied by an errata describing the changes. Resolution to the above items and editing is targeted to be complete by the 2 year anniversary date of WebCGM becoming a W3C recommendation. Dave Cruikshank will be responsible for the editing of the Recommendation.