cgmo-webcgm message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: The Companion file use cases story ( was RE: [cgmo-webcgm] ReviewChapter 2)
- From: "DULUC, Franck" <franck.duluc@airbus.com>
- To: cgmo-webcgm@lists.oasis-open.org
- Date: Mon, 20 Jun 2005 08:15:50 +0200
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.
Lofton,
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.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]