[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re[2]: [cgmo-webcgm] ISSUE: should DOM style properties be available in XCF?
Good points... I don't think anyone contradicts the usefulness of the feature... the issue is more about vendors being willing to implement. -- Benoit mailto:benoit@itedo.com Thursday, May 26, 2005, 4:05:52 PM, Dieter wrote: DW> Lofton, Benoit, DW> see my comments inline >> -----Original Message----- >> From: Lofton Henderson [mailto:lofton@rockynet.com] >> Sent: Thursday, May 26, 2005 7:56 PM >> To: Benoit Bezaire; cgmo-webcgm@lists.oasis-open.org >> Subject: Re: [cgmo-webcgm] ISSUE: should DOM style properties be >> available in XCF? >> >> >> At 09:38 AM 5/26/2005 -0400, Benoit Bezaire wrote: >> >I say 'we do it' or 'we don't do it', but it's not worth our time to >> >come up with a half way solution. Example: we either support: >> > >> ><grobject apsid="obj1" stroke-weight="200%" /> >> > >> >or we don't. >> > >> >But I (personally) don't want to spend time on this specification >> >enplaning how they can be simulated with this: >> > >> ><grobject apsid="obj1" asd:stroke-weight="200%" /> DW> Agreed. >> >> I agree, and I wasn't proposing to add such explanation to WebCGM 2.0 >> specification (in case we don't include it as standard 2.0 feature). >> >> >The S1000D should be able to figure that one out on their own. >> >> We would help S1000D to do it right in their specification, as they are a >> major user of ours. But it wouldn't affect WebCGM 2.0. DW> Experiences with interactivity and visibility in the past show that the DW> effort of helping them is probably more work than to simply implement it. DW> One technical problem with this approach: DW> if WebCGM 2.0 supports this DW> <grobject apsid="obj1" stroke-weight="200%" /> DW> then a uri like DW> abc.cgm#xcf(myxmlfile) DW> will do everything without scripting in one shot. DW> if the solution was DW> <grobject apsid="obj1" asd:stroke-weight="200%" /> DW> then a uri could load and apply the companion file, DW> however then the problem starts how to start the script that does the rest. >> >> >> >If other vendors are interested in supporting style properties in the >> >XCF, they should say so. >> >> I agree. I see no objections on technical grounds, and I see nice use >> cases. But if we put it in... >> >> Will vendors do it, in the timeframe we need for 2.0 completion and >> publication? DW> We will do it. DW> Regards, DW> Dieter >> >> -Lofton. >> >> >> >-- >> > Benoit mailto:benoit@itedo.com >> > >> > >> >Wednesday, May 25, 2005, 1:47:00 PM, Lofton wrote: >> > >> >LH> Some of us (SC) were pondering some questions about scope of >> >LH> the 2.0 work, schedule and S1000D time constraints, etc. By >> >LH> mistake, it actually turned into a technical discussion thread >> >LH> which should have played out on the TC list. I volunteered to >> >LH> summarize it to put the issue on the TC list for discussion. Here >> >LH> it is. >> > >> >LH> Dieter's comment that started the discussion: >> >LH> I had people here at the S1000D conference asking for >> >LH> modifying style properties using an XCF. Use case: A CGM contains >> >LH> two different configurations of a device. The user should only >> >LH> work with one configuration. Instead of making one >> >LH> configuration invisible, it should go to 20% display and stay >> >LH> visible as a reference image. Sounds like a reasonable request to >> >LH> me. >> > >> >LH> Implementation: >> > >> >LH> - load the CGM using the style described by the CGM elements >> > >> >LH> - apply an XCF and treat style property changes like DOMcalls >> > >> >LH> Ideally one would load the XCF right with the CGM, but I can >> >LH> alsoenvision use cases where you first load the CGM, and then >> >LH> apply the XCFat a later point in time. >> > >> >LH> To be clear, we're talking about the same set of style >> >LH> properties asdefined in WebCGM 2.0 DOM, for setStyleProperty. An >> >LH> XCF styleproperty example would look like, >> > >> >LH> <grobject apsid="obj1" stroke-weight="200%" /> >> > >> >LH> The principal concern that was expressed was about >> >LH> schedule: defining and putting it into the 2.0 spec, and more >> >LH> significantlyprobably -- implementing it in time. Note that part >> >LH> of the definingmust be done anyway, for the DOM part. I.e., the >> >LH> technical detailsof stroke-weight, text-font, etc would be >> >LH> identical for XCF asDOM. >> > >> >LH> A possible alternative was mentioned, if schedule looked too >> >LH> tight: CGMO helps ASD to define it as a namespace extension to the >> >LH> 2.0 XCF, forthe S1000D-2006 timeframe. E.g. >> > >> >LH> <grobject apsid="obj1" asd:stroke-weight="200%" /> >> > >> >LH> After sorting out some confusion, we all agreed what this >> >LH> wouldmean. Viewers would NOT be expected to handle the >> >LH> NS-extensionstyle property. I.e., execution of loadAndApply would >> >LH> not result ininterpretation of the NS-extension style property. >> >LH> Rather, it wouldbe the responsibility of the application (e.g., >> >LH> JavaScript app.) to useDOM to query/retrieve the NS extension, and >> >LH> then call the DOMsetStyleProperty method. CGMO could help out by >> >LH> writing a standardJS module that could be used by any ASD/XCF >> >LH> application. >> > >> >LH> If the functionality is indeed a requirement, then this is >> >LH> not an optimallong-term solution, but only a potential stopgap for >> >LH> scheduleexpediency. There may be other technical >> >LH> issues/objections about itas well.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]