RE: [cgmo-webcgm] QUESTION: cascading profile

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

Hi all,

What we decided is the replacement of the refloc attribute by linkuri at grobject level.

Then there are the companion files:
	- the ATA XCF version of the companion file on which I have been assigned an action to propose a DTD. In this framework It may also possible to directly the linkuri attribute. However, most of the time in our application and publishing process it is not possible to know the precise link at authoring time. The use of ata:refloc zttribute containing the business reference (like see IPC 23-24-24) may enable us to calculate within our consiltation application (PMA, AirN@v) to calculate a correct URI to be loaded in the CGM through the API.
	- the ATA SGML companion file (since GRExchange 2.10) designed for the exchange of business data together with graphics related information in order to enable complete Interactive Graphics Data Exchange and publishing systems leveraging. In this one, it may be that we keep the refloc in order to be consistent with iSpec 2200 business DTDs. But this is not to be taken into account by vendors for the viewing solution.

My view on the convergence with WebCGM is that if we can reach a state where there is no "graphical primitives difference" with WebCGM 2.0 will enable good implementation for everybody. We still need to discuss the subject for metafile description (some ideas were discussed in the mail thread related to "Cascading profile"; contributor Dieter, Dave and I).

Greetings from the windy and rainy US northeast ;-P

Regards,



Franck DULUC
Technical Data Research Manager
Customer Services - SDND
AIRBUS France

Phone: +33 (0)5 61 18 19 16
Fax: +33 (0)5 61 93 59 44
mailto:franck.duluc@airbus.com

Address:
BP D0611, 316, route de Bayonne
31060 TOULOUSE Cedex 9, FRANCE



-----Message d'origine-----
De : Cruikshank, David W [mailto:david.w.cruikshank@boeing.com]
Envoyé : mardi 25 octobre 2005 23:16
À : Robert Orosz; CGM Open WebCGM TC
Objet : RE: [cgmo-webcgm] QUESTION: cascading profile



 Point taken....from an illustating standpoint, if you embed links in
the cgm file, you need to specify something.  I was thinking in terms of
only having a ns variable (ata:refloc) in the ATA XCF and the script
writer converting it to a linkuri and run time and passing it through
the DOM.  Actually a URN would work better for this application, which
is what S1000D uses in it's XREF structure.

I need to sort through it a little in my mind.

Thx...dave

-----Original Message-----
From: Robert Orosz [mailto:roboro@AUTO-TROL.com]

Sent: Tuesday, October 25, 2005 11:23 AM
To: Cruikshank, David W; CGM Open WebCGM TC
Subject: RE: [cgmo-webcgm] QUESTION: cascading profile

Dave,

I'm not sure that I follow this completely.  You say that the ATA PPF is
now identical to WebCGM 2.0 except for T.16.2 (METAFILE DESCRIPTION).
This implies that T.24.1 (APPLICATION STRUCTURE ATTRIBUTE) is identical,
and the ATA has abandoned the refloc APS attribute in favor of the
linkuri APS attribute.  Then you make this statement:

"We could handle the linkuri/refloc debate through the ATA XCF, for
example."

Please explain and elaborate.

Thanks,

Rob

-----Original Message-----
From: Cruikshank, David W [mailto:david.w.cruikshank@boeing.com]
Sent: Tuesday, October 25, 2005 6:11 AM
To: CGM Open WebCGM TC
Subject: [cgmo-webcgm] QUESTION: cascading profile


All,

The ATA graphics group went through the PPF yesterday and  could
conceivably reduce the ATA delta profile down to the single table entry
of METAFILE DESCRIPTION.  At that point, does it make sense to even
specify an ATA PPF?  Or just reference the WebCGM 2.0 PPF?  There are a
few places where we could provide a delta, but nothing significant.  We
could handle the linkuri/refloc debate through the ATA XCF, for example.
There will still be an XCF, so it probably makes sense to specifiy an
ATA profile just to with a ProfileID just to introduce the XCF.

Thoughts?

Thx....Dave

Technical Fellow - Graphics/Digital Data Interchange Boeing Commercial
Airplane 206.544.8876, fax 206.544.9590 david.w.cruikshank@boeing.com



This mail has originated outside your organization,
either from an external partner or the Global Internet.
Keep this in mind if you answer this message.


This e-mail is intended only for the above addressee. It may contain
privileged information. If you are not the addressee you must not copy,
distribute, disclose or use any of the information in it. If you have
received it in error please delete it and immediately notify the sender.
Security Notice: all e-mail, sent to or from this address, may be
accessed by someone other than the recipient, for system management and
security reasons. This access is controlled under Regulation of
Investigatory Powers Act 2000, Lawful Business Practises.