[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [cgmo-webcgm] ISSUE: deprecation of old objBehaviors
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.
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.
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.
- From: Lofton Henderson [mailto:email@example.com]
- Sent: Monday, September 19, 2005 9:06 PM
- To: firstname.lastname@example.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 22.214.171.124.1, for converting 1.0 content to 2.0 content:
- view_context --> zoom+newHighlight
- highlight --> newHighlight
- highlight_all --> newHighlight
- ### end ###