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

["Cruikshank, David W" <david.w.cruikshank@boeing.com>]

 okay...I think I stirred up a hornet's nest here....I apparently misread the spec...

The S1000D hotspot/xref is actually tied to one graphic, i.e. one ICN (or illustration).  The question actually comes in when the xref within a graphic (or within running text in the SGML/XML) references a "figure"(parent of graphic) with an attribute of apsname.  That apsname can refer to multiple "graphics" (ICN's) within a figure.  To me this ends up a fat link, but should not impact the WebCGM viewer...it should impact the IETP application to determine how to present the link decision to the user.  I think Peter might think differently, in that the WebCGM viewer should have to deal with a fat link.  I guess in the XCF containing the fat link, the viewer has to figure out out do deal with it (do we have a test for this?), but in the creation of the XCF the creation script has to specify valid linkuri's that include the correct ICN.  In the case of the xref in the running text, the IETP software has to figure out the how to build the linkuri's that are compatible with the WebCGM spec...

I'll be meeting over the next week or so the discuss this with the S1000D folks.

Thx...Dave

-----Original Message-----
From: Benoit Bezaire [mailto:benoit@itedo.com] 
Sent: Tuesday, October 04, 2005 12:53 PM
To: cgmo-webcgm@lists.oasis-open.org
Subject: Re[2]: [cgmo-webcgm] QUESTION: do all apsid's in XCF have to be in WebCGM file?

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 
LH> call it an error or not, since there is no *comprehensive* policy 
LH> about how the error (or any error) is treated:  ""The target APS 
LH> must be present in the CGM file, if that is not the case, all 
LH> attributes of the current element are ignored."

LH> So yes, we can say it is an error because of the MUST, but that 
LH> doesn't add anything to the "if that is not the case" specification.  
LH> It would be just 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 
LH> like #2, if that is what people want.  Or we could say, "2. the 
LH> viewer shall halt 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 
LH> don't 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 
LH> that 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 
LH> don't cause ambiguous or undefined situations for viewers.  E.g., 
LH> maybe a whole class of drawings has identical structure and 
LH> 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 
LH> I understand it), where the single XCF is meant to serve for a class 
LH> of 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 
LH> 'filename' is present, it would be something like a lock-in, where 
LH> the viewer should advise/warn if there are unmatched apsids; else, 
LH> if not present or blank (""), 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