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

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

Lofton,

 

#2 means: no DOM modification (no new functions in the API) and no change in the basic strcture of the XML file (except in the placeholders desgined for that). This is equivalent to allow casading profile to work only on Chapter 6 for cascading.

 

#3 idea is: in the Metafile description cascaded files have to claim to which WebCGM they are compliant for allowing viewers to keep going or stop.

 

 

 

 

> 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.
I'm not sure what #2 means.  Explain please?  (As I understand, we expect cascaded profiles to define XCF extensions, no?)  Also I'm unclear about the meaning of #3.  Could you please give an example?  How would a viewer first check a file (presumably a script file) against the viewer's DOM-support capabilities?

Regards,
-Lofton.

 

 

 

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 : Lofton Henderson [mailto:lofton@rockynet.com]
Envoyé : dimanche 4 septembre 2005 22:02
À : dieter@itedo.com; DULUC, Franck; cgmo-webcgm@lists.oasis-open.org
Objet : RE: [cgmo-webcgm] WebCGM and cascading profiles (ASD, ATA, ...)

I agree with Franck's concerns.  I have a couple of questions (in-line below).  But let me also try to move this discussion in the direction of concrete actions that we should take.

At the July editors meeting, we spent some time discussing this.  We tried to encapsulate some sensible constraints into the just-published 2nd CD text of WebCGM 2.0 [1].  It is tricky, and not easy, to write it down.  See the first cut in section A.4.2.

[1] http://www.oasis-open.org/committees/download.php/14266/WebCGM_2_0_2nd.pdf

There are two aspects of A.4.2 to be settled:

1.) The details of what cascaded profiles should/shouldn't do, as discussed by Franck and Dieter (see below);

2.) And, the "normativity" of what we say in A.4.2.

What do I mean by #2?  Well, as #2 is currently written, it looks normative:  "profiles shall ...blah...", and it is in a normative sub-section.  In other words, as written, Cascade Profiles are one of the classes of things for which WebCGM 2.0 defines conformance requirements.  In other words, Cascade Profiles need to be added to the list in A.1 of things for which WebCGM 2.0 defines conformance (if we keep A.4.2 as normative.)

We need to consider whether we want A.4.2 to be stringently normative, and whether WebCGM 2.0 should have Cascade Profiles as one of its conformance-defined items (per current A.4.2 text).  There are certain disadvantages -- especially, normative text must be *much* more precise (must be testable), and will draw much closer attention and criticism (esp. if we process in W3C).  In other words, more controversy and more work for us. 

The alternative is to make A.4.2 non-normative, advisory.  That is, Cascaded Profiles are not one of the classes of things that conform to WebCGM 2.0, but WebCGM 2.0 would still give advice to profile-writers, about what they should and shouldn't do.  I.e., the effective content of A.4.2 would be the same (or whatever we decide the details should be, per below dialog below), it just wouldn't be presented as (testable) conformance requirements.

IMO, the advisory (non-normative) approach is probably just as effective with profile-writers, and is less work for us.  (I.e., I can't imagine that any profile writer would ignore non-normative "profiles should..." advice, but would pay attention to normative "profiles shall..." requirements.)

[Aside/references:  If I'm not making sense, maybe the "classes of product" stuff in these references will help.
[1] http://www.w3.org/TR/qaframe-spec/
[2] http://www.w3.org/TR/qaframe-spec/#implement-principle
[3] http://www.w3.org/TR/spec-variability/#spec-cat-cop  ]

One more comment / question in-line ...

At 01:39 PM 8/26/2005 +0200, Dieter  Weidenbrück wrote:

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.

I'm not sure what #2 means.  Explain please?  (As I understand, we expect cascaded profiles to define XCF extensions, no?)  Also I'm unclear about the meaning of #3.  Could you please give an example?  How would a viewer first check a file (presumably a script file) against the viewer's DOM-support capabilities?

Regards,
-Lofton.

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

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.