The Companion file use cases story ( was RE: [cgmo-webcgm] ReviewChapter 2)

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

Lofton, Dieter and all....

 

May I propose a new referendum (French poll to say no)? ;-).

 

More seriously, I do not intend to reopen something you may have closed during the last conference call; I agree with Dieter position: postpone.

 

However this email is a kind of refresher.

 

 

I was the use case and we had a lot of discussions on this topic. We finally agreed to put it aside in order to avoid a major deadlock and therefore no-go for the DOM/XCF stuff.

Things are clearer now for the user I am and I think I have tried to explain and position this requirement and the other ones covered by current DOM/XCF development, during a presentation that I did during Houston meeting (in a remote situation). Here is the summary:

        - There are requirements (the one addressed by WebCGM 2.0 DOM/XCF proposal that are considering adapting the CGM file when consulting it through a viewer in a user agent (e.g. IE Browser). This was existing before and was not normalized. Even more the features proposed were not so powerful. Conclusion, this is valuable work.

        - There are requirements not covered but which are not at all linked to the problematic of viewing but more to the ones raised by publishing requirements that us as Airbus but also Boeing, UK MoD have:

            - attach business information to graphical object and exchange these attachments in a normalized way

            - when publishing things like our AirN@v product, you often need to know what the possible target are in a file and verify them. This is currently of high importance for us.

 

Here is the sample:

    I have an illustrated parts catalogue graphic with items numbers and I want to attach information to the graphical objects: I will use this kind of descriptive companion file (like the one of the ATA).

    Then I am publishing AirN@v product and therefore I am trying to create link from my nomenclature. This descriptive companion file is used again to calculate and verify the accuracy of the link (every erroneous links are removed).

    Last I am browsing the results and click on the item link to the graphic. I will see the corresponding graphical object highlighted, with a colour change (or other style change), together with a screentip presenting me the vendor code for the selected item. This being enabled through the use of the WebCGM XCF file and the loadandapply function.

 

Now is the question of number of files: why two files and not only one? Indeed what I call descriptive file could be implemented through the current file (I say it with technical point of view, not an industrial one (publishing process, AirN@v, normalized DTD changes, costs,...)). Yet this makes the file an enumeration and Lofton is true saying that this file is not supposed to be loaded and applied. I would say: "Let the user mastering it". Is it really of importance if loadandapply the extracted content from the file meaning that the file will not be really changed?

 

Conclusion:

Postpone the use case (I am not 100% it has to be taken into consideration by WebCGM works) to the next steps and continue working on this very promising future.

 

Regards,

 

Franck.

 

-----Message d'origine-----
De : Dieter Weidenbruck [mailto:dieter@itedo.com]
Envoyé : jeudi 16 juin 2005 17:23
À : cgmo-webcgm@lists.oasis-open.org
Objet : RE: [cgmo-webcgm] Review Chapter 2

Lofton,

 

-----Original Message-----
From: Lofton Henderson [mailto:lofton@rockynet.com]
Sent: Thursday, June 16, 2005 5:01 PM
To: dieter@itedo.com; cgmo-webcgm@lists.oasis-open.org
Subject: RE: [cgmo-webcgm] Review Chapter 2

At 07:58 AM 6/16/2005 +0200, =?us-ascii?Q?Dieter__Weidenbruck?= wrote:
[...]

Comments, Benoit or anyone?

[DW] We have been discussing this, however, if we really  want to use the XCF this way we should probably

flag the file accordingly to distinguish it from "normal" XCFs. We need to think about a way then to add the "name" attribute to

such a list file. Right now we are not able to enumerate all APS IDs, types, and attributes: the name(s) would be missing.

It was my impression that this was NOT a principal use case, but then again I seem to recall that we have vacillated on this (Cologne and after) and maybe I missed a final determination.

As you say, it presents problems, as it is distinct from the other principal use cases of binding metadata to objects in file, both standardized metadata like linkuri and private application metadata.  Two problems at least, if it is an enumeration of metadata already in the metafile:

1.) the 'name' attribute, as you mentioned.
2.) you don't really want to loadAndApply such a file, do you?  (It is redundant, or if not totally redundant, then it's not an enumeration!)

Pragmatically, I would like to see a solution to this use case postponed, unless one of our user communities has a very strong need for it.  The text could be fixed by removing the use case, or inserting "partial" before "enumeration".
[DW] Agreed. The use case (hi Franck ;-)) is there, however, there are several implications (as we well know from discussions of the past). So 

let's postpone this discussion to 2.1. 

I suggest to change the text to point to this functionality in a future version of WebCGM. 

Should we generate an issue, just to force attention?  (And close it next Wednesday.)
[DW] Yes. 

[DW] Regards,

Dieter 
-Lofton.