ISSUE: should DOM style properties be available in XCF?

[Lofton Henderson <lofton@rockynet.com>]

Some of us (SC) were pondering some questions about scope of the 2.0
work, schedule and S1000D time constraints, etc.  By mistake, it
actually turned into a technical discussion thread which should have
played out on the TC list.  I volunteered to summarize it to put the
issue on the TC list for discussion.  Here it is.

Dieter's comment that started the discussion:

I had people here at the S1000D conference asking for modifying style properties using an XCF.  Use case:  A CGM contains two different configurations of a device.  The user should only work with one configuration.  Instead of making one configuration invisible, it should go to 20% display and stay visible as a reference image.  Sounds like a reasonable request to me.

Implementation:

- load the CGM using the style described by the CGM elements

- apply an XCF and treat style property changes like DOM calls

Ideally one would load the XCF right with the CGM, but I can also envision use cases where you first load the CGM, and then apply the XCF at a later point in time.

To be clear, we're talking about the same set of style properties as
defined in WebCGM 2.0 DOM, for setStyleProperty.  An XCF style
property example would look like, 

<grobject apsid="obj1" 
stroke-weight="200%"  />

The principal concern that was expressed was about schedule: 
defining and putting it into the 2.0 spec, and more significantly
probably -- implementing it in time.  Note that part of the defining
must be done anyway, for the DOM part.  I.e., the technical details
of stroke-weight, text-font, etc would be identical for XCF as
DOM.

A possible alternative was mentioned, if schedule looked too tight: 
CGMO helps ASD to define it as a namespace extension to the 2.0 XCF, for
the S1000D-2006 timeframe.  E.g.

<grobject apsid="obj1" 
asd:stroke-weight="200%"  />

After sorting out some confusion, we all agreed what this would
mean.  Viewers would NOT be expected to handle the NS-extension
style property.  I.e., execution of loadAndApply would not result in
interpretation of the NS-extension style property.  Rather, it would
be the responsibility of the application (e.g., JavaScript app.) to use
DOM to query/retrieve the NS extension, and then call the DOM
setStyleProperty method.  CGMO could help out by writing a standard
JS module that could be used by any ASD/XCF application.

If the functionality is indeed a requirement, then this is not an optimal
long-term solution, but only a potential stopgap for schedule
expediency.  There may be other technical issues/objections about it
as well.

Side Issue on Extensibility
=====

A side issue arose during discussion, that should be spun off and
addressed independently:  what constraints should WebCGM 2.0
prescribe for extensions of DOM functions or XCF definitions? 
WebCGM 1.0 was extremely stringent with its no-extensions policy. 
It is probably more difficult to do this in the DOM api environment, and
in the XCF environement (indeed, we put the extension mechanism into
XCF!).  

One specific question was:

Should [it be] prohibited to define viewer behavior in a cascaded profile

- at all?

- that alters WebCGM defined behavior?

- that is in conflict with WebCGM semantics/behavior?

Example: Load and apply an XCF, but don't apply "screentip" attributes

To be clear, defining viewer behavior would be, for example, saying that
the viewer must interpret asd:stroke-weight (instead of the JS
application doing it and calling standard viewer DOM).

WebCGM 2.0 currently has no extensibility constraints, neither on XCF nor
on the DOM functions (new functions, altered behaviors, etc).

Regards,
-Lofton.