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

[Lofton Henderson <lofton@rockynet.com>]

Here are my thoughts...

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

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

#1 is all that is said now.  We could additionally say something like #2, 
if that is what people want.  Or we could say, "2. the viewer shall halt 
and spontaneously combust".  Or ...

That brings up the real question:  should an XCF be tied to just one 
CGM?  To me, this is a user-requirement question (ATA, ASD, etc).  I don't 
care strongly how we answer it, but we ought to be clear.

My own opinion...  I don't see any reason for such a constraint, and that 
is probably the reason that we said the filename on 'webcgm' is 
"descriptive" (not normative).  We probably didn't want to constrain 
interesting applications that we haven't thought of, as long as they don't 
cause ambiguous or undefined situations for viewers.  E.g., maybe a whole 
class of drawings has identical structure and identical apsids internally 
-- a single XCF for the whole class would suffice for many useful 
tasks.  The next example step is something like the ASD example (as I 
understand it), where the single XCF is meant to serve for a class of 
related (not identically structured) CGMs.

I'd be fine with something like Dieter's suggestion:  if the 'filename' is 
present, it would be something like a lock-in, where the viewer should 
advise/warn if there are unmatched apsids; else, if not present or blank 
(""), the XCF is a generic one intended for application to a class of CGMs.

-Lofton.

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