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 on Style attributes [1 of 2]


[...part 1 of 2...]

Benoit et al --

Thanks again to Benoit for his thoughtful input on the DOM Style Properties question.

Per earlier message, I agree with his sentiment that it is not necessary, and is potentially wasteful of vendor resources, to give access through DOM Style Properties to all CGM V3 attributes.  For requirements like simulating flow, for which we have use cases, there is no need.

Exposing all attributes might have a potential benefit related to Accessibility, but ... personally, I'd prefer not to go there now.  I think the TC should answer an initial question before trying to list which specific Style Properties should be supported.

QUESTION:  Is our motivation to expose as DOM Style Attributes all of those CGM attributes (etc) that can sensibly be altered through DOM?  Or do we want to expose a restricted subset which support articulated use cases?

If the latter, then so far (at Seattle and since then) I have heard use cases for better supporting flow simulation, in wire-like things (implying some more stroke properties) and in tube-like things (implying more of either fill or line properties).

Part 2 to follow,
-Lofton.

At 11:43 AM 10/4/2007 -0400, Bezaire, Benoit wrote:
Hi All,
 
Here is my feedback on the Style attributes document:
http://www.oasis-open.org/committees/download.php/25270/Attributes_Table.pdf
 
I can't speak for other implementers, but exposing all those attributes in a DOM interface or declarative animation is a lot of work. Why not try and narrow down the list? So far, I just don't see how a good number of the attributes help us achieve our list of requirements. I think some examples would help me a lot. Now this is just off the top of my head, but I think that a number of suggested animatable styles require a lot of development work (for our viewer). In the table below, I list my own preference:
 
Stuart's suggestion            Benoit's suggestions    Comments
Line Type                      Ok                      Could be used to show flow
Line Cap                       remove                  Isn't line type sufficient?
Line Join                      remove                  Isn't line type sufficient?
Line Type Continuation         remove                  Isn't line type sufficient?
Line Type Initial Offset       Ok                      Useful, but unclear, hard to implement.
Marker Type                    Ok                      Hard to implement
Marker Size                    Ok                      Hard to implement
Marker Colour                  Ok                      Hard to implement
Text Score Type                remove?                 Is anyone implementing this? test case?
Interior Style                 Ok
Hatch Index                    Ok
Pattern Index                  Ok
Edge Type                      Ok                      Never understood diff between line and edge.
Edge Visibility                remove                  Never understood diff between line and edge.
Edge Cap                       remove                  Isn't Edge Type sufficient?
Edge Join                      remove                  Isn't Edge Type sufficient?
Edge Type Continuation         remove                  Isn't Edge Type sufficient?
Edge Type Initial Offset       Ok                      unclear and hard to implement.
Fill Reference Point           remove                  Isn't changing the pattern/hatch enough?
 
Just a note. In my own personal opinion; I think I would dedicated resources to transparency and animation along a path as oppose to the Style attributes.
 
Feedback would be appreciated.
 
Regards,
Benoit


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