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: Changing 1.0 functionality

Having looked at some of Chris's comments, I am concerned about one aspect.  Some of his comments effectively are asking for changes to 1.0 functionality.  We will see more of this, coming from I18N and WAI. 

Some of our responses may involve (in part), "that is standardized 1.0 functionality, and changing it should be considered beyond the scope of 2.0."  I.e., forward compatibility and continuity are strong criteria, unless there are pretty good reasons to deviate.

That cannot be a blanket policy, but I think we (CGMO) need to be extremely careful about initiating changes to 1.0 stuff on our own, unless the reasons are really compelling.  (And even then, WAI and I18N may consider their reasons compelling.)  If we're not careful, we could end up opening and arguing issues, and getting to REC much later than the already draft WG Charter projection.

Here are three examples, for purposes of illustration:

1.) Safe.  we removed the 'viewport' PARAM.  This might be considered "safe" -- a simple functionality that no one implemented in 5 years.  (W3C allows specs to drop functionality at CR stage, if it's unimplemented).

2.) Unsafe.  I consider the object behaviors mapping issue to be "unsafe" -- while we might be able to convincingly justify the change in how 2.0 viewers handle view_context ("it was broken in 1.0, doesn't map into the new 2.0 behaviors set, etc"), I think we would establish a regrettable precedent if we changed how 'highlight' and 'highlight_all' behave in 2.0 viewers (because the 1.0 behavior was clearly defined, implemented, and maps simply to a 2.0 equivalent):

3.) Inbetween/indeterminate.  Benoit's recent presentation of compositing model issues presents a more complex (and less obvious) case.  My point in mentioning it, and the point of this message (again), is that I want to measure any changes to the listed functionality (all 1.0 stuff) against a "really compelling" criterion (and honestly, I haven't yet digested all of his excellent analysis, nor formed an opinion):


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