RE: [cgmo-webcgm] WebCGM and cascading profiles (ASD, ATA, ...)

[Dieter Weidenbrück <dieter@itedo.com>]

Hi Franck,

good point that needs to be clarified. Please find my comments inline.

> -----Original Message-----
> From: DULUC, Franck [mailto:franck.duluc@airbus.com]
> Sent: Friday, August 26, 2005 1:05 PM
> To: cgmo-webcgm@lists.oasis-open.org
> Subject: [cgmo-webcgm] WebCGM and cascading profiles (ASD, ATA, ...)
>
>
> Hi all,
>
>       I know you may think I am sleeping during our
> discussion but it is not the case. I am listening to you all
> trying to follow-up the works wuth my user perspective.
>
>       Last wednesday, I heard someting on which I want to
> react and would like to have people views.
>       Just before Dieter left us, we were discussing what to
> do with a non-WebCGM file (like a cascaded one from the ATA).
> I heard things like "if it is ATA instead of WebCGM, I will
> ignore it because it could be unsafe trying to handle
> something for which the viewer has not been developped".
>
>       Taking the time to think about it:
>               - there is not interst for ATA and ASD to
> cascade profiles because:
>                       - files will not be handled by viewers
>                       - Users like Boeing, MoD UK and Airbus,
> if publishing Industry-compliant profiles compliant CGM
> files, will have to translate them to use them with common
> available viewers (based on WebCGM).
>               - the logical conclusion is then forget
> cascading profiles and eveybody has to adopt WebCGM as
> defined by OASIS TC.
This is not what we have in mind, and we want to do everything
to avoid this situation.

>
>       What a very dark future! I do not really think this is
> the one we have been working on together for years now. So
> let's say tht we want to keep going with cascading profiles.
> Below is my view on this subject:
>
> A) Context
>       1) I understand the point of view of implementors: too
> many implementations are not reasonnable in terms of
> costs/profits ratio.
>       2) It is dangerous to have a viewer handling a file for
> which it has not been designed.
>       3) Today, availablle viewers are displaying CGM files
> whatever the profile is, based on their capacity to display
> CGM prrimitives (without considering the profiles).
Agreed, and this won't change.


>
> B) Requirements
>       1) Viewers have to know if their DOM is compliant with
> the one for which the file has been defined
There is no way that the viewer can detect this, unless we find
a way that a viewer can read/digest a profile document.

>       2) Users have to have the capability to tune CGM
> primitives usage (Style guides, forbidden primitives)
This is an interesting concept for the future, I consider this one
out of scope for WebCGM 2.0

>
> C) Assumption:
>       1) There is no need to extend the DOM for an industry group:
>               1.a) the DOM as designed is fully enabled in
> terms of CGM and allows access to industry specific data that
> are stored in the XCF file in the exetensible parts.
>               1.b) any requirement to enrich the DOM is of
> common interest for CGM users and is therefore to be
> developped with the reference standard (WebCGM).
Agreed, this is exactly the intention.

>              
> D) Way of Working for cascading profile
>       1) Each profile is to identify from which WebCGM it is
> derived, allowing therefore to idnetify what is the DOM version.
>       2) No DOM/XCF (for the WebCGM) parts to be allowed to
> cascaded profiles.
>       3) Viewers to check first if the file is derived from
> somthing they understand in terms of DOM.
Agreed, this is what we want to do. The WebCGM DOM should be
rich and good enough to cover all requirements from WebCGM as
well as those from potential cascading profiles.

>
> E) Conclusion
>       1) This way allows users to have their requirements
> fully covered
>       2) Implementation are secured
>       3) This is just a simple email and is not therefore the
> magic solution that can be found in less than 5 minutes (or
> ten when I ma writing english). However, I think this the
> basic idea to be discussed and investigated. The other one
> that i foresee is "dark future".
>       4) I hope I will get comments and reactions.
You are summarizing the intentions very well, and this is my understanding
how WebCGM and cascading profiles will work.

The problems that I saw would arise exactly in those cases
that you want to avoid as well, e.g.
a cascading profile changes the DOM or the semantics of the XCF,
the viewer doesn't know about it and fails, or
the vendor has to implemented various behaviors.

Let me add one more comment:
Organisations writing a cascading profile off WebCGM 2.0 should be
encouraged to forward any requirement regarding DOM and XCF to
CGM Open for consideration and incorporation into the next version
of WebCGM.

Best regards,

Dieter

>
> Best 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, FRANCE
>
>
>
> 
> 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.
>