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?


Lofton, Benoit,

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%"  />
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.
Experiences with interactivity and visibility  in the past show that the
effort of helping them is probably more work than to simply implement it.
One technical problem with this approach:
if WebCGM 2.0 supports this
	<grobject apsid="obj1" stroke-weight="200%"  />
then a uri like
	abc.cgm#xcf(myxmlfile)
will do everything without scripting in one shot.

if the solution was
	<grobject apsid="obj1" asd:stroke-weight="200%"  />
then a uri could load and apply the companion file,
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?
We will do it.

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