Re[2]: [cgmo-webcgm] QUESTION: do all apsid's in XCF have to be in WebCGM file?

[Benoit Bezaire <benoit@itedo.com>]

Hi,

I've read the entire thread... and will respond inline to all three
emails. You should probably start at the bottom (Dave sent the first
email) and work your way up. I'll reply in chronological order...

Tuesday, October 4, 2005, 12:43:51 PM, Lofton wrote:

LH> Here are my thoughts...

LH> First, from a narrow perspective, it is somewhat academic whether we call
LH> it an error or not, since there is no *comprehensive* policy about how the
LH> error (or any error) is treated:  ""The target APS must be present in the
LH> CGM file, if that is not the case, all attributes of the current element
LH> are ignored."

LH> So yes, we can say it is an error because of the MUST, but that doesn't add
LH> anything to the "if that is not the case" specification.  It would be just
LH> as good to say,  "If the target APS is not present in the CGM file, then:
LH> 1.) all attributes of the current element are ignored.
LH> 2.) the viewer shall issue an advisory or warning."

LH> #1 is all that is said now.  We could additionally say something like #2,
LH> if that is what people want.  Or we could say, "2. the viewer shall halt
LH> and spontaneously combust".  Or ...
I would not be in favour of 'halting' the process, but that's my
opinion. (Again, it's starting to be a bit late to make such changes).

LH> That brings up the real question:  should an XCF be tied to just one
LH> CGM?  To me, this is a user-requirement question (ATA, ASD, etc).  I don't
LH> care strongly how we answer it, but we ought to be clear.
And I would prefer we don't reopen old issues :)
It was my belief that an XCF could map to multiple CGMs. If there's
a problem with that, users say it now.

LH> My own opinion...  I don't see any reason for such a constraint, and that
LH> is probably the reason that we said the filename on 'webcgm' is 
LH> "descriptive" (not normative).  We probably didn't want to constrain
LH> interesting applications that we haven't thought of, as long as they don't
LH> cause ambiguous or undefined situations for viewers.  E.g., maybe a whole
LH> class of drawings has identical structure and identical apsids internally
LH> -- a single XCF for the whole class would suffice for many useful 
LH> tasks.  The next example step is something like the ASD example (as I
LH> understand it), where the single XCF is meant to serve for a class of
LH> related (not identically structured) CGMs.
I think we are diverging from Dave's original question a bit. The
S1000D users are important to us. Dave, if what I said below doesn't
satisfy the S1000D users; could you please explain what the problems
are.

LH> I'd be fine with something like Dieter's suggestion:  if the 'filename' is
LH> present, it would be something like a lock-in, where the viewer should
LH> advise/warn if there are unmatched apsids; else, if not present or blank
LH> (""), the XCF is a generic one intended for application to a class of CGMs.
I don't like that very much (and I'm not convinced it's the solution
S1000D users need - granted, partially because I don't understand the
problem- :).

LH> -Lofton.

LH> At 12:14 PM 9/26/2005 +0200, Dieter  Weidenbrück wrote:
>>Hi Dave,
>>
>>The filename attribute on the WebCGM element can only point to one CGM file,
>>hence there is a conflict when using the same XCF for multiple CGMs.
>>However, this attribute is descriptive only.
It is descriptive and not required. I believe it is so, since we
wanted to have XCF that could map to multiple CGMs. I see the
'filename' attribute as an FYI type of thing.

>>The processing rules in 5.3 say:
>>"The target APS must be present in the CGM file, if that is not the case,
>>all attributes of the current element are ignored."
>>and
>>"The target APS (the parent element) must be present in the CGM file, if
>>that is not the case, all child elements of the current element are ignored.
>>"
>>So if an APS appears in the XCF that is not present in the CGM file, we have
>>a violation
>>of one of these rules here, because it clearly says "must".
>>The error processing is not further defined, it just says "ignore". From
>>this one could derive
>>that it may be acceptible to have unknown APSs in an XCF.
>>
>>IMO it is a bit shaky to build a solution for S1000D on these rules, only
>>trusting that the viewer will safely ignore the unknown APSs. A viewer (or
>>interpreter) may simply choose to bring up a warning dialog or write a
>>message into a logfile to inform the user about the error.
>>
>>I think it would be helpful to establish a clear rule for this case, e.g.
>>If the filename attribute is empty or not present on the WebCGM element, the
>>file is considered as a "multi-purpose" XCF, and it may contain APSs that do
>>not exist in a particular CGM the XCF ist applied to.
I don't really like the idea of adding semantics to the 'filename'
attribute. This has a big impact on implementations and it's late to
be adding so much importance to an attribute that was 'meaningless' a
week ago.

But I have to state that I'm not sure I grasp the S1000D problem
completely.

>>NOTE:
>>There is an issue of course as soon as we start dealing with metadata. Any
>>metadata element at top level (child of webcgm element) would be added, no
>>matter, which CGM is open.
>>
>>Not really happy with this...
>>I understand and know where this comes from, but then if we open up this
>>door
>>we will have to face situations where people stuff everything into one
>>single
>>XCF because "all Ids on a plane are unique", and then the viewer has to deal
>>with this.
>>Any other ideas?
>>
>>Dieter
>>
>>
>> > -----Original Message-----
>> > From: Cruikshank, David W [mailto:david.w.cruikshank@boeing.com]
>> > Sent: Saturday, September 24, 2005 12:39 AM
>> > To: CGM Open WebCGM TC
>> > Subject: [cgmo-webcgm] QUESTION: do all apsid's in XCF have
>> > to be in WebCGM file?
>> >
>> > I've been thinking about the biggest issue facing S1000D in
>> > adopting WebCGM 2.0.
>> >
>> > The HOTSPOT element id attribute cooresponds to the figure level.
>> > FIGURE can contain multiple GRAPHIC elements.  This is like
>> > the GRAPHIC/SHEET relationship in the ATA.  That means that
>> > the S1000D apsid attribute within the hotspot can point to
>> > one of a number of graphics
>> > (SHEETs) in the figure.  This means that there is potentially
>> > a one to many relationship between hotspot elements and
>> > WebCGM files.  We talked about this a little in Munich, but
>> > didn't some to a resolution and it's an issue that keeps
>> > bothering Peter.  Presumably apsid's are required to be
>> > unique across all GRAPHICS within a FIGURE.
I'm not familiar with S1000D (HOTSPOT, FIGURE, GRAPHIC/SHEET), so
please ignore my ignorance. We (WebCGM 2.0) have defined a mapping
between XCF and a single WebCGM Picture. How does S1000D plan to take
our WebCGM 2.0 XCF and mapping to their language? It would be great if
you or someone from the S1000D community could generate a solid
example.

>> > In WebCGM 2.0, we define apsid as: "The unique identifier of
>> > the Application Structure for the given WebCGM file"
>> > Does this imply that the identifier has to appear in the
>> > given WebCGM file?
In my opinion, no.

>>   Consider an XCF with might contain
>> > apsid's that span multiple WebCGM files.  Would a viewer
>> > application fail when it didn't find a match in the current
>> > WebCGM file?, or ignore it and not load it into the DOM?
Our current implementation will simply skip over APS that are not
found (i.e., not found or invalid apsid).

That's was the intention when I wrote the processing rule, nobody
objected. If it's not clear enough, I don't have any objection in
clarifying it.

>> > As a side note, I don't think anyone in the S1000D community
>> > has implemented a HOTSPOT element that contains apsid's
>> > spanning multiple GRAPHIC elements, but the potential is there.
>> >
>> > Ideas?
>> >
>> > Thx...Dave Cruikshank
>> > Technical Fellow - Graphics/Digital Data Interchange Boeing
>> > Commercial Airplane 206.544.8876, fax 206.544.9590
>> > david.w.cruikshank@boeing.com
>> >
>> >




-- 
 Benoit   mailto:benoit@itedo.com