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: deprecation of old objBehaviors

At 09:14 PM 9/19/2005 +0200, Dieter  Weidenbrück wrote:
one more comment on this:
if we deprecate object behaviors, this has not only an impact on WebCGM content, but also on content containing links to objects inside a WebCGM, e.g. HTML.

Very good point.  It is not just about WebCGM content.  Links coming from other content types won't be carrying version identifiers, like WebCGM instances do.  (And actually, it might affect a CGM-to-another-CGM link as well -- you don't automatically know the version of the link source.)

 Therefore I agree with REC 1, and I strongly suggest to require the viewer to map "old" behaviors to new ones as described.
Otherwise we would render useless any EcmaScript code or hrefs in HTML that uses the old behaviors.

We should discuss how we want to handle it.  There are a couple of variables:

1.) viewer behavior:  map any occurrence of the old-3 to the v2 set?  or execute old-3 as defined in 1.0?

2.) manditoriness:  viewers MUST?  or viewers SHOULD?

3.) default:  how should v2 viewer default known-v1 content (the v2 default is zoom+newHighlight, the v1 default is full picture highlight)?  How should v2 viewer default objBehavior on version-unknown link fragments?

Dieter suggests viewers MUST map view_context, highlight, highlight_all.  That's fine with me.

What do others think?

I would also accept that a v2 viewer should *always* default as the content were v2 (zoom+newHighlight).

Other thoughts?

This would also establish a reliable behavior for editors when opening a v1.0 WebCGM and saving it as a v2.0 WebCGM. The editor could silently replace old behaviors with new ones.

I agree, when converting v1 to v2, you must do the mapping (since presence of view_context, etc., in a v2 file would be invalid.)

SUMMARY.  The way that we're heading, a v2 viewer would give somewhat different object behavior than a v1 viewer, when handling the same v1 content.  Are people comfortable with that?  [And if you are uncomfortable with it ... is there any alternative, other than *not* deprecating the old-3, and simply leaving the old-3 in as valid v2 content?]


From: Lofton Henderson [mailto:lofton@rockynet.com]
Sent: Monday, September 19, 2005 9:06 PM
To: cgmo-webcgm@lists.oasis-open.org
Subject: [cgmo-webcgm] ISSUE: deprecation of old objBehaviors
Ref:  http://lists.oasis-open.org/archives/cgmo-webcgm/200509/msg00093.html
Comments #14, 26

ISSUE sub-1:  Should the 3 deprecated object behaviors remain in the EBNF of WebCGM 2.0?

ISSUE sub-2:  Should WebCGM 2.0 define a mapping for the 3 deprecated object behaviors?


Dieter wrote, concerning our three old object behaviors, view_context, highlight, highlight_all, "The 3 deprecated behaviors [should be] still a part of the EBNF, they may be found in any existing file [...] If we strike the behaviors from the EBNF, a WebCGM 1.0 file can not be a valid WebCGM 2.0 file IMHO." 

This is a direct consequence of our definition of "deprecate":  a deprecated feature is prohibited for 2.0 generators and 2.0 content, but 2.0 interpreters (viewers) that support 1.0 must support the feature.  See A.2.  This "deprecate" definition was borrowed from MathML, and we have reviewed it, but perhaps without appreciating its implications.  It does mean that 1.0 content containing 2.0-deprecated features is not valid 2.0 content. 

This is an unavoidable consequence of removing anything from a standard.  One can mitigate the real impact by putting backward-compatibility requirements on viewers (e.g., like our "deprecate" definition).

Here is a list of affected things, were deprecated in 1.0 2nd Release and are (currently) removed altogether in 2.0:

** multi-picture
** continued APS
** symbol libraries

And these things are deprecated in 2.0 and may be removed altogether in the future:

** viewport PARAM
** some compression types of TILE & BITONAL
** the 3 old object behaviors

It is a tricky issue, how to deprecate and remove something from the standard.  No matter how you do it, at some point valid Version n content cannot be valid Version n+1 content.  The only alternative is to leave everything in the standard forever, as valid content.

Back to the EBNF ... it defines the version 2.0 language.  If the 3 obj. behaviors are deprecated, according to our definition of deprecated, they are not part of the 2.0 language.

If anyone has an alternative, coherent, actionable way to define deprecation and handle things that we think should be removed from the standard, please present it. 

RECOMMENDATION sub-1:  Leave it as in CD2 -- our definition of "deprecate", the deprecation of 3 old objBehaviors, and the 2.0 EBNF.

RECOMMENDATION sub-2:  Add Dieter's suggested mapping (cmmt #26) to, for converting 1.0 content to 2.0 content:
view_context --> zoom+newHighlight
highlight --> newHighlight
highlight_all --> newHighlight

### end ###

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