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