[cgmopen-members] for the archive...

[Lofton Henderson <lofton@rockynet.com>]

CGM Open members (& observers),

I'm resending this, because I want it to be in our CGMO mail archive [1] 
(for easy future reference).

-Lofton.

[1] http://lists.oasis-open.org/archives/cgmopen-members/

Title: Stylable CGM

Stylable CGM

Draft: 4 August 2002
By: Lofton Henderson

Foreword

This is an outline of goals, constraints, and proposals for a Stylable CGM solution as proposed at the Frankfurt TC meeting. It serves both as the basis for developing a CGMO TC solution, as well as a starting point for the proposed XML 2002 paper.

Abstract

For reference, this is the abstract that Cruikshank (& Henderson) submitted for XML2002...

The CGM Open Consortium is made up of CGM technology vendors, users, and standards participants. Working with W3C graphics resources, the CGM Open Consortium developed the WebCGM Profile as an approved W3c Recommendation in 1999. Since that time several CGM products have appeared making use of WebCGM to deploy interactive graphics in the Web environment. The interoperability of WebCGM has been demonstrated several times by the vendors involved in CGM Open. Recently, DOM functionality has been demonstrated by these vendor products and, the CGM Open Technical Committee initiated a project to standardize this functionality through the development of a DOM.

During recent CGM Open Technical Committee work on an API to WebCGM Viewers (WebCGM DOM), the need arose for communicating sometimes temporary or transient changes to the graphical attributes (style) in the WebCGM instance. CGM inherently contains presentation information through the attributes applied to the graphical primitives. The committee noted a parallel between this situation and the problem faced by CSS1 with legacy HTML versions (HTML 3 and 4) where presentation attributes were integrated into the instance. Although CGM is a binary format, a WebCGM instance has a well-defined tree structure of named elements, and the CSS approach therefore should be applicable. The approach taken by the CSS1 solution for HTML is being extended to cover the requirements for the externally styling of WebCGM.

Introduction

At Frankfurt TC meeting, the problem of communicating element attribute changes to an implementation of the WebCGM DOM led to a proposal for a CSS-like styling solution for WebCGM. The applicability of CSS derives is confirmed by the following statement in CSS2:

"CSS can be used with any structured document format,.." [CSS2 ch.2]

WebCGM is a structured document format.

Note. There seems to be no good reason to reference CSS1 instead of CSS2. We will use CSS2 as our reference for this specification. The CSS2-CSS1 changes are described beginning with:

CSS2 builds on CSS1 and all valid CSS1 style sheets are valid CSS2 style sheets. The changes between the CSS1 specification (see [CSS1]) and this specification fall into three groups: new functionality, updated descriptions of CSS1 functionality, and changes to CSS1.

Amongst the new functionality, the subsequent bullet list mentions: "An extended selector mechanism, including child selectors, adjacent selectors, and attribute selectors." These features may be handy (esp. attribute selectors) for specifying a styling scheme to apply to WebCGM.

Use cases

(We should describe a handful of use cases, to clarify what we are trying to accomplish with DOM. That's the only way to answer some of the later design questions. Volunteers?)

Specific problem definition

Scope

The styling solution discussed at Frankfurt has a limited scope -- not all aspects of a CGM file need to be controllable with styling, and access to individual elements is out of scope (unless a single element comprises the entire content of an APS). Only the items enumerated at Frankfurt need to be controllable. These are repeated in the following sections.

Highlight functionality

It was decided that the method of highlighting graphical objects in support of DOM functionality should be viewer dependent. I.e., there should be a 'highlight' attribute, which causes an object to be highlighted in a way which is otherwise unspecified -- the method is at the discretion of the viewer.

Control of attributes

The styling solution is being pursued as a consequence of a particular requirement on the WebCGM DOM/API: the DOM needs to support the function of setting values and unsetting them as well. That is to say, changing line color from black to red requires the application to "remember" that the original line color was black so that it can be restored. Unsetting values is tricky because it potentially requires knowledge of the initial graphical state of an element. In a true full DOM model, this would be achievable by 'get' functions, which are complementary to 'set' function. However, the requirements of this graphical API the have a scope and granularity that falls short of a proper, full DOM model, as explained in the following.

The control of attribute values is divided into two levels of granularity: those that apply to the whole picture -- 'pictureScope' -- and those that apply to an entire APS -- 'apsScope'. Individual CGM graphical primitive elements within a picture or an APS cannot be addressed and styled. Whenever an attribute is set, all the elements of the type (line, edge, text, or fill) that the attribute applies to will be affected. So if there are, within an APS, several different line elements with different line colors, for example, all of them will be uniformly changed to a new value. The problem with reversing the change per a classical DOM model is twofold:

• a 'getColor' inquiry at the APS granularity in principle does not have a well defined answer -- the APS doesn't have a color, it is the individual line elements within the APS which have the color.
• if the 'get' and 'set' granularity were lowered to individual primitives, it would be very inefficient for accomplishing the

It addition to directly setting values of graphical attributes, two other methods of attribute control are required. They are intensity and scaling. Intensity may apply to color attributes or a raster image, while scaling can apply to text height or line and edge weight.

Control of color attributes

The following functions were identified to support control of color attributes:

• Picturescopelinecolor
• Picturescopeedgecolor
• Picturescopefillcolor
• Picturescopetextcolor
• Picturescopemarkercolor
• APSscopelinecolor
• APSscopeedgecolor
• APSscopefillcolor
• APSscopetextcolor
• APSscopemarkercolor
• Picturescoperasterintensity
• APSscoperasterintensity

Color attributes may be set absolutely by RGB values or by a relative intensity in the range of zero to one. The relative intensity is a scale factor that is to be applied to the existing color.

Control of line/edge weight

The following functions were identified to support control of line and edge weight attributes:

• Picturescopelineweight
• Picturescopeedgeweight
• APSscopelineweight
• APSscopeedgeweight

Line and edge weight may be set absolutely in mm or by a relative scale factor greater than zero. The relative scale factor is applied to the existing line or edge weight.

Control of character height

The following functions were identified to support control of the character height attribute:

• Picturescopecharacterheight
• APSscopecharacterheight

Character height may be set absolutely in mm or by a relative scale factor greater than zero. The relative scale factor is applied to the existing character height.

(Issue: what happens to the width of restricted text elements? Is it altered proportionately to the change in height? The most obvious answer is "yes"-- it doesn't seem very useful to change only the height and distort the text.)

About the above-enumerated attributes

The above-listed attributes deviate from the actual CGM attribute model. They either don't exist in the CGM model (e.g., character height scale factor), or they behave differently (e.g., the scale factor for line weight is applied to the current modal line weight, not to the implementation-dependent nominal line width as is the case with CGM's 'line width scale factor'

It is also worth observing that the required ways of setting weights, heights, etc, will be independent of and supersede the various CGM modes for those attributes, e.g., the line width specification mode. The same is true of the color attributes (the current color selection mode is over-ridden.)

Key Issues

Summary

• binary or clear text? [propose: clear text]
• WebCGM tree model
• general: how hard to try for alignment with CSS, SVG, etc?
  • -> propose: not too hard -- no one really cares about joint/shared code
  • -> propose: borrow principles, customize for WebCGM
• what subset of CSS selectors model?
• applicability of CSS inheritance model?
• what about cascade, and specificity, precedence?
  • user style sheets: applied from outside of WebCGM instance [propose: yes]
  • author style sheets: embedded or referenced from inside [propose: not now, maybe later]
  • user agent style sheets: basically, ua-dependent defaults [propose: no]
• what names to use for standard WebCGM elements?
  • try for common names with SVG? [propose: no]
  • cgm Clear Text names? [propose: maybe, would be sensible, as many implementations have parsers]
• what about Frankfurt attributes that don't exist in WebCGM
  • attributes types themselves
  • attribute values (e.g., "50%")
• how will WebCGM (virtual) stylesheet interact with or be reflected in DOM? What are some user scenarios or use cases?
• what is the processing model, relating WebCGM instance, DOM, viewier, external style sheet, etc?
• should WebCGM 2.0 introduce a "processing instruction" that allows reference to external style sheet?

Constraints:

• don't alter any standard WebCGM syntax or semantics

Binary or clear text

CSS is a clear text format, which makes it really easy to put together stylesheets manually (is "manual" a use case? or are the use cases all automatic machine processing?). The rule to set all H1 elements to blue is:

H1 {color: blue}

CGM is a binary format. Nevertheless, these transactions between (external) user stylesheets and binary CGM will be through some interface or API (the DOM?), and therefore the translation can be handled by the implementation.

The CGM stylesheets should be text, e.g.,

grobject {color: red}

to turn all 'grobject' APSs to red. (See next sections about modelling the tree and the selectors scheme).

A related issue has to do with some un-defined aspects of the CGM DOM/API. How will values of some things like 'linkuri' data be communicated through the DOM? In CGM, they are user-unfriendly SDRs (structured data records). In WebCGM, those are binary.

Alternatives:

1. each API function would specialize it's parameter list for the information content. E.g.,
   • setScreenTip (apsid, "a simple ApsAttr")
   • setLinkUri (apsid, "first substring", "second substring", "third substring")
2. pass a binary SDR
   • setScreenTip (apsid, ptr-to-binary-coded-SDR)
3. pass a clear text SDR
   • setScreenTip (apsid, "14 1 'a simple ApsAttr'")
   • setLinkURI (apsid, "14 3 'first substring' 'second substring' 'third substring'")

Note. This is presented in terms of a simple API in some classical programming language like C. I don't know what it would look like if the WebCGM API were for example built on top of XML DOM core, in some O-O programming language, per "An Approach to a CGM DOM".

Proposal. None yet. If DOM binding were like above in classical programming language, then option #1 is most appealing (but most inflexible). If it is built on generic XML DOM, then #3 looks most appealing.

WebCGM Tree Model

Modeling APS nodes

To apply a CSS-like styling solution, we need to be clear about a tree model for CGM graphics. This is mainly for the purpose of defining selectors (CSS selectors act on a tree structure). It also affects design issues of inheritance and cascading.

WebCGM tree structure is simple:

metafile

--> pictures

----> APS elements (nested)

------> graphical prims/attrs (leaf nodes)

Note that multiple pictures are deprecated in WebCGM 1.0 (2nd Edition).

What are the element nodes at the APS level? This is an issue. If we draw analogy to a markup grammar, there are two choices:

1. APS type="grobject | para | .."

   <==> <aps type="grobject | para | ..">

2. APS type="grobject | para | .."

   <==> <grobject ..> | <para ..> | ..

In #1, the APS 'type' parameter is combined with the APS element and modelled as (XML) elements of distinct kinds. In #2, the tree is modelled with one kind of element/node -- APS -- which carries a 'type' attribute (attribute in the XML sense). Although they are equivalent, #2 is most appealing and cleaner when selectors are chosen and applied.

Tentative choice. #2.

Modeling APS attributes

Oops, I just noticed... the styling solution apparently applies only to the graphical aspects, not the APSattr aspects, which are apparently in the DOM... so the following can probably be ignored...

Related to this is how to model the CGM APS attribute elements within an APS. These might be, for example, screen tips or links, i.e., respectively CGM APS attribute elements whose 'type' parameter is 'screentip' or 'linkuri'. They could be modelled as:

1. child elements of their containing APS
2. XML attributes on their containing element

#2 is most appealing, but there is a problem. Some ApsAttr types can occur multiple times on one element. One way to handle this would be to define an attribute multiplicity and pass a more complex argument that encodes the multiplicity. I.e., if there is a single linkuri, its parameter is of the form of an SDR with three string members:

"14 3 'first-substring' 'second-substring' 'third-substring'"

But if there were two linkuri on one APS, then it could be parameterized in the stylesheet (and DOM) in a couple of ways:

1. an SDR with two SDR members
   • "1 2 'first-linkuri-3-member-SDR' 'second-linkuri-3-member-SDR'"
2. a list-of-SDR approach
   • "'first-linkuri-3-member-SDR' 'second-linkuri-3-member-SDR'"

The difference is subtle. The first encodes the two distinct linkuri parameters as a CGM-formatted nested SDR. The second uses the CSS/HTML "list of" approach to parameters.

Either one is ugly -- by the time you have considered whatever quoting might be needed for the CSS syntax, and the nesting of stuff in the CGM Clear Text SDR coding, you could be looking at several levels deep in nested quotes.

No specific recommendation yet. However, it does seem promising to handle the un-XML-like multiple-attribute problem as a packaging issue in the API/DOM.

Selectors

CSS Selectors are how you address the elements within the document, to which your styling should be applied. CSS2 has a table of selectors capabilities.

Looking at this table, these seem like the absolute minimal selector pattern matching set:

* -- Matches any element [universal selector]

E -- Matches any E element (i.e., an element of type E) [type selector]

E#myid -- Matches any E element ID equal to "myid" [ID selector]

Also very useful would be the attribute selectors (so that you could match, or example, on 'name' attribute):

E[foo] -- Matches any E element with the "foo" attribute set (whatever the value).

E[foo="warning"] -- Matches any E element whose "foo" attribute value is exactly equal to "warning".

We could accomplish a lot with these. In particular, note a capability that would be available if we were to make the convention that a picture is a type of element. All of the pictureScope and apsScope variants could be handled by the selectors mechanisms, instead of some other special syntax. For example,

picture {lineColor: 50%}
grobject[name="foo"] {lineColor: 100%}

would dim all lines in the picture to half-intensity, except for those in the grobject whose name attribute had the value "foo". (Note. This relies on some specificity rules that we haven't explained yet.) Even though multiple pictures are deprecated, you could use the picture element type in combination with ID selector in a multi-picture metafile.

There are other interesting selectors in the CSS selectors table as well, for example the contextual selectors which allow you to match depending on child, descendent, and sibling relationships in the tree. Also, the link pseudo-classes (link, visited) and the dynamic pseudo-class selectors (hover, active, focus) might have some interesting application.

Inheritance

It seems clear that the graphical styling attributes ought to inherit. I.e., if you are going to make the "automobile" grobject turn red, then it ought include the wheels -- i.e., all other potential nested components (APS) ought to be affected.

(...more tbd...)

Cascade, precedence, specificity

The CSS cascade defines a number of possible sources of styling: author, user, user-agent default. That is also the basic order of importance: author styles override user styles override user-agent default styles. There are numerous sources of styles:

1. intra-element style attributes;
2. a single style element in the document header;
3. @import rules;
4. link elements (HTML) or stylesheet PIs (XML) to external stylesheets
5. (unspecified) user-agent mechanism that allows user to supply stylesheet
6. user-agent default stylesheet

For CGM, all graphical attributes are well-defined, and therefore "user-agent default styles" makes no sense. The CGM basically comes with complete author style information (including CGM defaults). For this CGM styling application, apparently only #5 is also relevant -- external application of user stylesheet.

It seems clear that we want "user" styles (#5) to have precedence over author styles (the completely defined CGM styles). This could be done by forcing !important into every CGM style declaration, but that seems inefficient.

Recommendation. For CGM styling, define cascade precedence the opposite of CSS -- user overrides author.

Specificity ...tbd, but basically the CSS rules are okay. When there are clashing styles, the most specific wins. E.g.,

picture {lineColor: 50%}
grobject#foo {lineColor: 100%}

dims all lines except those in the grobject with ID value of foo, because that rule's selector is more specific than the 50% rule.

Processing model

So far, there are no proposals for the overall architecture of the system.

• How are styling rules communicated to the viewer?
• Is there some sort of rule-by-rule interface?
• Or, do you have to pass an entire stylesheet at a time?
• How do you turn off a stylesheet after you have applied it and want to go back to default? (i.e., unapply the styles)
• How does the styling interface to the viewer relate to DOM? (DOM presumably will 'get' and 'set' all the APSattr stuff)

Synopsis

blah...blah...blah

References

1. Cleveland minutes DOM definition (available at http://www.cgmopen.org/meetings/cgmo_tech_cleveland_01.html)
2. Orlando minutes (availabe at http://www.cgmopen.org/meetings/cgmo_tech_orlando_02.html#review)
3. Frankfurt minutes (available at http://www.cgmopen.org/meetings/cgmo_tech_frankfurt_02.html)
4. "An Approach to CGM DOM" (available at http://www.cgmopen.org/technical/approach_to_cgm_dom.html)
5. WebCGM 1.0 Second Release (available at http://www.w3.org/TR/REC-WebCGM/)