[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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%" /> 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. >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? -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]