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[2]: [cgmo-webcgm] QUESTION: do all apsid's in XCF have to be in WebCGM file?


At 03:53 PM 10/4/2005 -0400, Benoit Bezaire wrote:
[...]
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 :)

Indeed, we must have some discipline and refrain from that.  I'm becoming acutely aware of this OASIS Process requirement,
"If Substantive Changes are made to the specification after the public review, whether as a result of public review comments or from Member input, then the TC must conduct another review cycle. The specification may not be considered for approval by the TC as a Committee Specification until it has undergone a review cycle during which it has received no comments that result in Substantive Changes to the specification."
It was my belief that an XCF could map to multiple CGMs. If there's
a problem with that, users say it now.
I agree, as it stands the XCF can map to multiple CGMs, which is what we want I think, and I understood what the users wanted.

[...]
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- :).

I'm also fine to leave it as is.  It seems general enough to cover lots of usage scenarios, including the S1000D scenario, as I understand it.  We should refrain from over-constraining it.

I could support clarification of the wording, along the lines of:  "If the target APS is not present in the CGM file, all attributes of the current element are ignored."  Whether or not we want to require or recommend viewer advisory/warning that the "ignore" case has been triggered ... I generally favor making such information available, but don't feel strongly.

-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


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