© ITEDO Software 2004 S1000D and CGM Dieter Weidenbrueck Paris July 21, 2004

© ITEDO Software 2004

S1000D and CGM

Dieter WeidenbrueckParis July 21, 2004


Content

• Current problems with profile usage• Suggestion for new S1000D profile• Cascading CGM Profiles• The new XML Companion File

Architecture• The WebCGM DOM


Current Problems with CGM Profile

• A CGM file is GREXCHANGE compliant if it follows the rules described in the ATA specification

• This is expressed in the metafile descriptor string:MFDESC '"ProfileId:ATA GRAPHICS.GREXCHANGE",

"ProfileEd:2.6"

• Such a file can be tested against GREXCHANGE 2.6



• S1000D specifies in 7.3.2, 5.0:• “S1000D CGM V4 Profile”

• S1000D specifies in 7.3.2, 1.2:• “S1000D restrictions of and extensions to the

ATA TIFF and CGM profile GREX V2.6 or later are detailed in Para 5.2 below.”

• This is not enough to define a valid profile.


Current Problems with CGM Profile• One example: BEGIN METAFILE

• “The ATA specific notation and limitation of the BEGIN METAFILE parameter value identifying a CGM graphic through the ATA GNBR (see 5-2-4.7.2.3, table entry T.15.1, of ATA iSpec 2200) shall be interpreted to hold the S1000D ICN in the form "ICN-icn". The ATA fixed parameter length of 32 bytes has to be abandoned as above for raster graphics. “

• So according to S1000D, the following is legal:• BEGMF 'ICN-1B-B-291101-M-C0419-00571-A-01-1';

• According to ATA GREXCHANGE, it is not.



• Additional problem:• “…GREXCHANGE 2.6 or later”

• This leads to further ambiguity. GREXCHANGE is at 2.9 right now.



• The Metafile Descriptor String does not contain any information that this file is compliant to the S1000D Profile.

• Thus a validator can only test against the GREXCHANGE profile, and fail

• The current situation does not allow for the creation of testable S1000D-compliant CGM files.


Suggestion

• The EPWG has several choices:• Go with WebCGM without changes• Go with GREXCHANGE without changes• Write an S1000D profile

• <waves of enthusiasm crossing the room…/>


Cascading CGM Profiles


The current way

• CGM:1999 defines rules for profiles:• Complete Profile Pro-Forma (PPF) referencing

the Model Profile (MP).

• The PPF is a huge table with about 200 rows

• ATA GREXCHANGE profile is a complete PPF, with a most rows identical to the MP, and a relative handful of difference rows

• S1000D references ATA GREXCHANGE with a handful of differences


The Motivation

• Almost nobody wants to write a full PPF• (including the CGM geeks)• There are only minimal changes

between the profiles as far as graphics is concerned

• Most differences relate to metadata


The Concept

• WebCGM is a solid “generic” technical graphics profile for the web

• It is a full PPF• It provides a good foundation for the

creation of other profiles• Other profiles could be defined by a

“delta PPF” from WebCGM


The Concept

• WebCGM is defined by reference to MP (in a full PPF)

• ATA could be defined by a delta-PPF reference to WebCGM• This is very likely to happen soon

• S1000D could be defined by a delta-PPF reference to either WebCGM or ATA


The Concept

• By following links through the cascade, any item in any profile can be discovered

• Using a regularized markup grammar for the PPF (XHTML), it would be possible to generate a full PPF for any profile along the cascade


Benefits

• Creating a profile becomes a straightforward process

• If it is based on WebCGM with minimal graphic changes, implementations are very likely to happen

• If WebCGM is revised, the derived profile could issue a new version as well and inherit the changes


The New XML Companion File Architecture


Current situation

• XML Companion Files have been discussed for several years

• No standardization yet• Binding between objects in CGM and

XML is unclear• Viewer behavior is undefined


The Concept

• CGM Open has defined a complete architecture for XML companion files• Extendable DTD• Viewer behavior• DOM accessibility


Example 1

<?xml version="1.0" encoding=UTF-16) ?>

<webcgm version="1.0" filename="abc.cgm">

<grobject apsid="myObj1" screentip="This is object 1.">

<linkuri uri="http://www.cgmopen.org" behavior="_blank"/>

</grobject>

</webcgm>

• Binding between APS ID in CGM and apsid on XML object


Example 2

<?xml version="1.0" encoding=UTF-16) ?>

<webcgm version="1.0" filename="abc.cgm">

<bindByName apstargetname="myName1" screentip="This is object 1.">

<linkuri uri="http://www.cgmopen.org" behavior="_blank"/>

</bindByName>

</webcgm>

• Binding between APS name in CGM and apstargetname on XML object


Example 3<?xml version="1.0" encoding=UTF-16) ?><webcgm version="1.0" filename="abc.cgm"

xmlns:s1000dns="http://namespace_declaration"> <grobject apsid="myObj1"

screentip="This is object 1.„ s1000dns:viewcontext="5 5 25 25">

<s1000dns:hotspot id="myHSID" apsid="myObj1„ apsname="myName1"

coords="10 10 20 20"/> <linkuri uri="http://www.cgmopen.org"

behavior="_blank"/> </grobject></webcgm>• Extending the DTD using namespaced attributes and

elements


Example 4<?xml version="1.0" encoding=UTF-16) ?><webcgm version="1.0" filename="abc.cgm"

xmlns:s1000dns="http://namespace_declaration"> <bindByName apstargetname="myName1"

screentip="This is object 1.„ s1000dns:viewcontext="5 5 25 25">

<s1000dns:hotspot id="myHSID" apsid="myObj1„ apsname="myName1"

coords="10 10 20 20"/> <linkuri uri="http://www.cgmopen.org"

behavior="_blank"/> </bindByName></webcgm>• Extending the DTD using namespaced attributes and

elements


Viewer behavior

• The CGM loads the CGM file first• The CGM viewer will then load the

content of the XML file and „apply“ it to the CGM content

• The application can access any detail of the companion file content using DOM functions


Example<script type="text/javascript">

var cgmDoc = document. myCGMViewer.GetWebCGMDocument();

cgmDoc.firstPicture.applyCompanionFile("comp.xml");

</script>

• The CGM viewer now holds all information in memory.

• Access is possible using DOM functions


Summary

• CGM Open publishes standard WebCGM DTD

• Other organizations can derive their own DTD from it

• Loading and access to details stored in the XML companion file will be standardized as well


Finally - The WebCGM DOM


The WebCGM DOM – Overview

• Interfaces to access all application structures and their attributes

• Some limited styling at APS level possible• Colors• Line weights• Text fonts

• DOM Event Model


Fundamental interfaces

• Metafile• Picture• AppStructure• Attr• Text


Important functionality

• Traversal of DOM tree• Access to all APSs and their attributes• Access to all namespaced attributes and

elements loaded from a companion file• DOM Event model for mouse events


Availability

• WebCGM DOM and Companion File Architecture will go to feature freeze on August 11, 2004

• This work plus some other changes will become WebCGM 2.0

• CGM Open will work with W3C to publish WebCGM 2.0 as a Recommendation asap

• Technical work is expected to finish in 2004


CGM Open Recommendations for S1000D• If possible,

• create an S1000D profile using the cascading profile technique

• develop an S1000D companion file DTD based on the WebCGM DTD

• build applications using the WebCGM DOM


Credits

• CGM Open• Dave Cruikshank, Boeing (DTDs)• Lofton Henderson (Cascading Profiles)• Benoit Bezaire, ITEDO (WebCGM DOM,

XML Companion Files)


Q & A

Documents

© ITEDO Software 2004 S1000D and CGM Dieter Weidenbrueck Paris July 21, 2004