[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [xliff] XLIFF migration policy
Tony, Sorry for not hitting the deadline on this discussion but I was out of town/busy catching up the past two weeks. I do have some thoughts on the policy which follow. 1. In the "Rules for Major vs. Minor releases:" section the following statements are made concerning certification. > As a guideline, "Minor" releases: > 1. Shall be comprised of small changes that would not require > re-certification of supporting tools or technologies And later: > As a guideline, "Major" releases > 1. May be comprised of significant architectural changes that may > require re-certification of supporting tools and technology. Do we want to reference "certification" in any form? Wouldn't this be better if we simply said 'modification' as follows? > As a guideline, "Minor" releases: > 1. Shall be comprised of small changes that would not require > modification of supporting tools or technologies > ... > As a guideline, "Major" releases > 1. May be comprised of significant architectural changes that may > require modification of supporting tools and technology. 2. In "Support for Existing Users" it talks of "Deprecated support for changed elements, values or attribute names, ..." Shouldn't this be "Support for deprecated elements, values or attribute names, ..."? It isn't support we are deprecating, is it? 3. Again in "Support for Existing Users" we may want to be explicit that we are talking about attribute value lists. We may also want to include a statement about those previously open lists that we've enumerated and allowed for extensibility through namespaces. I've revised the bullet point below. * Enumerated attribute value lists are a potential issue, if they are closed. Therefore, no attribute value list will be closed that existed as an open list in a previous release. When one of these attribute value lists is enumerated, a formalized extension mechanism will be provided." 4. The "Rules for Name Changes" essentially says that we won't change the name of required elements and attributes. If the semantics change and the name changes, it is an addition of a new element/attribute and we have the luxury of deprecating the current element/attribute or not. Thus, the statement should read (or something to this effect): "The names of required elements and attributes will not be changed. However, a new required or non-required element/attribute may be added that has different semantics and which replaces the current required element/attribute; thus, making the replaced element/attribute non-required." 5. In both the "User Migration Assistance" and "Marketing, Public Relations and Education" sections there is a requirement for us to produce certain collateral material through the use of "will" and "shall". I suggest that we soften this to "may" since, although this material is highly desirable and we have every intent to produce it, it shouldn't be a requirement. cheers, john >>> Tony Jewtushenko <Tony.Jewtushenko@oracle.com> 8/2/02 7:28:46 AM >>> All: Below is the Migration Policy document with all suggestions implemented, including those from the latest discussion involving Mark, Gerard and Christian. An item shall be added to next week's meeting agenda for final comments & request for motion / second to conduct an email ballot to formally accept the policy statement. Regards, Tony -- Tony Jewtushenko mailto:tony.jewtushenko@oracle.com Sr. Tools Program Manager direct tel: +353.1.8039080 Product Management - Tools Technology Team Oracle Corporation, Ireland
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC