RE: "Compound" Application Structure

[DULUC Franck <franck.duluc@airbus.com>]

Title: "Compound" Application Structure

Agree but This is in the CGM standard. I thought it was not (I should have read more carefully). I remmember many discussions with John Gebahrdt of the impossibility to really structure the CGM files (due to the mismatch of the drawing structure and the logical structure that would have be needed).

 

I still have concern with the meaning of what unicity means in this context.

 

I also take the opportunity of this mail for announcing to the members that I will come back to us soon with a new CGMOpen Mantis customisation for the interoperability project. My long silence is due to some holidays taken following my recent happy event. But I am still here and still listen to you.

As The summer is here, is it planned any CGMOpen Meeting in Washington, during next ATA meeting ?

 

Regards,

Franck DULUC
AIRBUS FRANCE
SDN7 - B.P. D0611
316, route de Bayonne - 31060 TOULOUSE Cedex
FRANCE
Phone: (33)5.61.18.19.16   Fax: (33)5.61.93.59.44
mailto:franck.duluc@airbus.com

-----Message d'origine-----
De : Dieter Weidenbrueck [mailto:dieter@itedo.com]
Envoyé : jeudi 10 juillet 2003 12:36
À : DULUC Franck; 'cgm open members mailing list'
Objet : RE: "Compound" Application Structure

Franck,

 

for WebCGM we initially thought it would be a good idea to have a "continued APS" feature:

 

BEGAPS "myID1"

...

ENDAPS

BEGAPS "myID2"

...

ENDAPS

BEGAPS "myID1"

...

ENDAPS

 

The reason for this was to get around issues with grouping elements that are not in a sequential Z order.

 

In the meantime, the intent is to change this back to what it had been before because an ID must be unique in an SGML/XML environment. This is one of the requirements that came out of the DOM considerations.

 

My expectation is that this will be discontinued with the next version of WebCGM. I have no information about whether any product actually implemented it or not.

 

Cheers,

Dieter

-----Original Message-----
From: DULUC Franck [mailto:franck.duluc@airbus.com]
Sent: Donnerstag, 10. Juli 2003 12:28
To: 'cgm open members mailing list'
Subject: "Compound" Application Structure

Dear all,

        Found in CGM the following paragraphs. As I understand them, it may happen that many APS have the same Id in the CGM files, and therefore has to be handled as grouped (considered as one object).

        1) Am I right ?
        2) If yes what is the meaning of a unique ID, as unicity check becomes impossible (against which criteria this unicity is checked).

        3) Support by tools (editors, generators, viewers) in one word interoperability?
        4) Any comments or feedback to share.

Regards,

-------------------------------------------------------------------------------------------------------------------------------------------------

6.13 Application Structure Elements
6.13.1 Introduction
Application structures (APS), which provide access to metafiles for applications such as text/graphics integration at
levels of granularity finer than the picture level, may be defined in Version 4 metafiles. An APS is defined within a
picture body as follows:
BEGIN APPLICATION STRUCTURE
APPLICATION STRUCTURE ATTRIBUTE
.
.(Arbitrary number of application structure attributes)
.
BEGIN APPLICATION STRUCTURE BODY
.
.(Graphic primitives, attributes, and control elements in any order)
.
END APPLICATION STRUCTURE

The BEGIN APPLICATION STRUCTURE element has three parameters which define the type, indentifier, and
inheritance mechanism for the APS. The APPLICATION STRUCTURE ATTRIBUTE provides the capability for
applications to associate non-graphical information with APSs. This element has two parameters which define the
type of APS attribute, and the data record containing the actual data.
APSs defined in this manner enable applications to structure and manage the metafile in a manner meaningful to
the application.
If a BEGIN APPLICATION STRUCTURE element is encountered with an 'identifier' parameter which matches the
identifier of another BEGIN APPLICATION STRUCTURE in the same picture, then the second (and any
subsequent) occurrence shall be construed as continuing the definition of the APS begun by the first occurrence.
The location of the APS in any possible hierarchy of Application Structures shall be defined by the first occurrence
of a BEGIN APPLICATION STRUCTURE element with the given identifier. An APS with a given identifier may not
be nested within an APS with the same identifier. An APS with a given identifier shall not match the identifier of an
APS in another picture in the same metafile. The 'type' and 'inheritance' parameters of the BEGIN APPLICATION
STRUCTURE element of any continued APS shall match the values present on the first occurrence of the APS.

6.13.2 Location of and access to Application Structures

One or more APSs may occur within a picture body, or totally within another APS. APSs may be classified into
classes or categories meaningful to a particular application by using the application structure type parameter. An
APS shall be uniquely identified (using the application structure identifier) within the metafile (see 6.13.1 regarding
the mechanism of continuing the definition of Application Structures). An APS may occur only within a picture body
but may not occur within a local segment. However, an APS may contain local segments as long as the segments
begin and end within the APS body.

Franck DULUC
AIRBUS FRANCE
SDN7 - B.P. D0611
316, route de Bayonne - 31060 TOULOUSE Cedex
FRANCE
Phone: (33)5.61.18.19.16   Fax: (33)5.61.93.59.44
mailto:franck.duluc@airbus.com