this is my final email before I'm off on vacation (flights in 6 hrs!) ...
There's no problem with your comments coming when they did - better late than never. The discussion can be finalized and if appropriate, the ballot sent around via email after Tuesday's meeting.
I've responded to your issues point by point below... following the ">TJ " tags.
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?
>TJ actually, "certification" was intentional language and in this usage doesn't break any OASIS rules (at least not that is obvious to me). "Modification" pretty much means the code will definitely be changed, whereas, that may not be the case. "Certification" means the product will be tested according to the new spec, and possibly code may require change, but not necessarily. "Certification" is only a no-no if we imply that WE, the TC will provide some sort of certification service and stamp of approval - whereas those who implement XLIFF support for their tools would be expected, as a matter of basic software engineering proces, to verify that their tool supports a given XLIFF version based on their own certification criteria. I'd prefer to keep the language as it is in this case, or alternatively find something other than "modification", since this may not be the case.
> 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?
>TJ OK, yes the wording was awkward - and can stand to be changed.
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."
>TJ OK
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."
>Ok, but "required or non-required" just sounds a little strange to the ear. Maybe you can find some alternative way of expressing the concept?
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.
>TJ Ok, no objection.
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
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: