OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

cgmo-webcgm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

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."
"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.
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
we will have to face situations where people stuff everything into one
XCF because "all Ids on a plane are unique", and then the viewer has to deal
with this.
Any other ideas?


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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]