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] COMMENTS: Chapter 3


Ben, All --

(Actually, I'm answering myself here...that's okay, I spend a lot of time talking to myself...)

At 11:23 AM 5/6/2008 -0600, Lofton Henderson wrote:
At 12:37 PM 5/6/2008 -0400, Bezaire, Benoit wrote:
I thought that at last weeks telecon, most of the vendors (if not all) agreed to have a ACI file in a specific folder/directory that would apply for all CGM files. Not an ACI file for each 'load' operations as currently described by the specification. That was my understanding.

It is my impression that we did not reach a firm decision

If we did, it is not very clearly recorded:
http://www.oasis-open.org/apps/org/workgroup/cgmo-webcgm/download.php/28177/20080430_WebCGM_TC_Telecon_minutes.pdf

This topic has become a mess.  We have several intersecting issues here.  I just spent a big chunk of time reviewing everything (mail, 2.1 text, etc).  My attempt to dissect the issues:

Issue ACI-1:  Should viewer-side font substitution syntax be standardized?
Issue ACI-2:  Should viewer-side defaultStuff be standardized?
Issue ACI-3:  Should they be in separate files or the same (ACI) file?
Issue ACI-4:  Should font-sub be once-per-viewer, or once-per-metafile, or both?
Issue ACI-5:  Should defaultStuff be once-per-viewer, or once-per-metafile, or both?

I claimed in an earlier message,
http://lists.oasis-open.org/archives/cgmo-webcgm/200805/msg00001.html ,
that ACI-1 and ACI-2 have been resolved "yes".  We should stop arguing about that stuff unless (per that message) someone moves now to reverse those decisions, and a majority agree to reverse them.  That should be our first order of business.

If the font-sub and defaultStuff requirements survive, onward...

I do recall (at the 4/30 telecon) a fair amount of sympathy for the once-per-viewer approach.  That said, the *only* recorded discussion that relates to once-per-viewer or once-per-metafile is:

http://lists.oasis-open.org/archives/cgmo-webcgm/200801/msg00021.html
http://lists.oasis-open.org/archives/cgmo-webcgm/200801/msg00025.html

That thread seemed to imply some agreement on a separate, standalone ACI file, with the possibility that it could also be a XCF prelude section (or external reference from XCF prelude).

For font-sub at least, Dieter & I seemed to both endorse "both".

Then, after that thread the ACI proposal was put into the CD draft, with both PI referencing and #fragment referencing.  Dieter made a detailed critique, and I'm not satisfied that we have answered his specific objections:

http://lists.oasis-open.org/archives/cgmo-webcgm/200804/msg00037.html

We never did have time for issue discussion/resolution before the CD publication.  So I think we need to sort it out now, with some attention to details and specific objections.

I have just reviewed everything I can find, and I have some sympathy for Dieter's arguments about complexity that is introduced by including a separate ACI-referencing syntax in the fragment. 

(That sympathy stems in part from Monday's SC discussions with Chris, in which it becomes clear that strong simple profiles and a cadre of conforming implementations is the reason that W3C needs to continue with 2.1, instead of trying to cajole the A&D community to switch to SVG.)

In fact, it might get even uglier, as the proposed changes don't address:  fragments in the 'src' parameter of Interface WebCGMMetafile; implications on applyCompanionFile in Interface WebCGMPicture.

However, some of what is said about the order of things perhaps overlooks this text, identical in 2.0 and 2.1:
http://docs.oasis-open.org/webcgm/v2.1/cd01/WebCGM21-IC.html#webcgm_3_1_2_6

[[[
The fragment syntax can be used to load and apply an XML Companion File (XCF) together with the WebCGM file. An interpreter that supports WebCGM DOM shall load the WebCGM file first. Then it shall load and apply the XML Companion File specified by the IRI (resolving a relative IRI if necessary). Finally it shall apply the XCF before the first display of the CGM.
]]]

Note the mandated pause between load-apply and initial display of the CGM.  It is also interesting to re-discover this stuff we wrote in the last 3 bullets of 5.7 (identical text in 2.0 and 2.1), although I don't think it has any practical impact with our one-picture WebCGM design:
http://docs.oasis-open.org/webcgm/v2.1/cd01/WebCGM21-DOM.html#Fundamenta

I would like to further explore whether something along these lines meets the needs of the users/advocates:

1.) an ACI file XML language/syntax that includes both the fontSub elt (and sub-elements) and defaultStuff elt (and sub-elements)
2.) support for once-per-viewer as well as once-per-metafile.
3.) get rid of the ACI fragment syntax extensions;
4.) allow reference to an ACI from an XCF, with the clear proviso that it shall be ignored in any case after the initial display of the CGM, i.e., any case where the XCF reference is "too late" according to the proviso of 3.1.2.6. 

About #4, I'm not a big fan of the PI method -- not a good reason, just unenlightened prejudice.  But why not add an element of our own, that must occur first, and contains the external reference?

The tricky bit here is #3.  On every OS (Operating System), is there a suitable OS-dependent solution to attach the ACI to the viewer, on an OS-by-OS basis, and can the users who need this stuff live with that?  (Which comes full circle back to Ben's remembrance from the telecon.)

Users?  Vendors?  (Have I proposed something for everyone to hate?)

-Lofton.



From: Cruikshank, David W [mailto:david.w.cruikshank@boeing.com]
Sent: Tuesday, May 06, 2008 12:03 PM
To: Bezaire, Benoit; CGM Open WebCGM TC
Subject: RE: [cgmo-webcgm] COMMENTS: Chapter 3

3.1.1.1: As per our latest discussions, an IRI fragment cannot be used to load a ACI file
 
I'm not sure I remember that decision being formalized.  Is it that it "cannot" be used, or the vendors won't support?
 
thx...Dave
 

Technical Fellow - Graphics/Digital Data Interchange
Boeing Commercial Airplane
206.544.3560, fax 206.662.3734
david.w.cruikshank@boeing.com
 


From: Bezaire, Benoit [mailto:bbezaire@ptc.com]
Sent: Tuesday, May 06, 2008 7:07 AM
To: CGM Open WebCGM TC
Subject: [cgmo-webcgm] COMMENTS: Chapter 3

3.1.1.1: As per our latest discussions, an IRI fragment cannot be used to load a ACI file
3.1.1.2: As per our latest discussions, 'resrcterm' cannot use "aci(", i.e. fragment syntax should be the same as WebCGM 2.0
3.1.1.3: switch "resrcurl" with xcfterm
3.1.1.5: swithc 'resrcterm' with xcfterm, delete references to "Application Configurable Items" and ACI.
3.1.2.7: remove entire section
3.2.1.5 Grnode: should we clarfiy in here if 'grnode' has a bounding box (i.e., geometry)? Supports styling?
3.4: didn't we decide to do something about background: Enable | Disable?
 


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