OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cgmopen-members message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: re: "Compound" Application Structure




Regards, 
Don.
Larson CGM Software. 
713-977-4177x102


  > 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 ?
Techncialy you are correct but as Dieter pointed out that in retrospect
this (disjoint APS with same ID) is not a good idea in practice.

  > 	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?

In our Editor and Viewer, we treat this as 2 separate GrObjects even though
the ID's are the same.  

In our editor the non-unique ID is not a problem becasue we select by 
graphically 
"picking" GrObjects.  Likewise in our viewer this is also not a problem since 
they are treated as 2 separate objects each with it's own hot-spot region 
defined
either explicitly with the REGION attribute or implicitly by the APS contents.

  > 	4) Any comments or feedback to share.
  > Regards,

I agree with Dieter though that the concept of disjoint APS structures with 
same ID being treated a one object is not a good idea and should be deprecated
in the WebCGM standard.

 
  > 
----------------------------------------------------------------------------
  > ---------------------------------------------------------------------
  > 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




  > -- NextPart --
  > You may leave a Technical Committee at any time by visiting
  >  
http://www.oasis-open.org/apps/org/workgroup/cgmopen-members/members/leave_
  > workgroup.php


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]