[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [tab-askthetab] FW: [askthetab] errata question
Hal, Curious, in what respect do you think "the Board got the definition wrong" on errata? I have a number of problems with the current errata process, not the least of which is the distinction between OASIS standards and specifications for the errata process. Just a foot fault for the unwary. Hope you are having a great day! Patrick PS: Personally I don't see errata as correctly back to the "original intent," but correcting a text to what we presently think is correct. May or may not be what we would have written at the time, but that really doesn't matter. What matters is our best answer today that fits with the rest of the text. Clears away a lot of thorny issues and gets to the point of what we should say today. William Cox wrote: > Hal - > > Good point. > > Would you please take Mary's note (back to the questioner), the > discussion on this issue, and your previous memo, and draft a brief > reply that we can post on the Ask The TAB part of the Wiki? > > It would be good to have a draft early next week so we can publish > this month. > > Thanks! > > bill > > Abbie Barbir wrote: >> Hal >> Well said >> Regards >> Abbie >> >> >> -----Original Message----- >> From: Hal Lockhart [mailto:hal.lockhart@oracle.com] >> Sent: Tuesday, January 20, 2009 3:37 PM >> To: mary.mcrae@oasis-open.org; Ask The TAB >> Subject: RE: [tab-askthetab] FW: [askthetab] errata question >> >> Actually, the original concept behind OASIS errata was that errata >> should be an attempt to restore the original intent of the document. >> This primarily falls into two categories: >> >> 1. Mistakes. >> 2. Clarifications. >> >> As I pointed out in the memo I wrote which led to the definition of the >> current process, one of the most common errors is to leave out the word >> "not" in a sentence. Correcting such a sentence is technically an >> incompatible change, although perhaps the error was recognized from the >> first and ignored by implementers. >> >> Therefore I would argue that there are (admittedly rare) cases where an >> "incompatible" change might be allowed. However as a practical matter, I >> think it is reasonable to say that when things are computer enforced, >> e.g. by Schema validation, then it may be most practical to enforce the >> current no incompatible changes policy. However if the point in question >> is only specified in text, I think it would be reasonable to allow if >> the original intent is clear to all. >> >> Personally I think the Board got the definition wrong, but there is only >> so much I can do to influence the TAB, let alone the Board. >> >> Hal >> >> >>> -----Original Message----- >>> From: Mary McRae [mailto:marypmcrae@gmail.com] On Behalf Of Mary McRae >>> Sent: Thursday, January 15, 2009 12:13 PM >>> To: 'Ask The TAB' >>> Subject: [tab-askthetab] FW: [askthetab] errata question >>> >>> FYI - my response to Jacob. >>> >>> Mary >>> >>> -----Original Message----- >>> From: Mary McRae [mailto:mary.mcrae@oasis-open.org] >>> Sent: Wednesday, January 14, 2009 9:32 PM >>> To: 'Jacob Westfall'; 'AskTheTAB@lists.oasis-open.org' >>> Subject: RE: [askthetab] errata question >>> >>> Hi Jacob, >>> >>> While your question was directed to the TAB, I wanted to make sure >>> you were aware of the definition of "substantive change" as stated in >>> the OASIS TC Process: >>> >>> "Substantive Change" is a change to a specification that would require >>> >> >> >>> a compliant application or implementation to be modified or rewritten >>> in order to remain compliant. >>> >>> That means that if an implementation currently validates against an >>> existing normative schema, and the proposed changes would result in >>> that same implementation no longer validating, the change is deemed >>> >> substantive. >> >>> For instance, if a list of items is required to be in a particular >>> order and you change that order, an existing valid instance would no >>> longer validate. Similarly, if you changed the spelling or case of an >>> element name >>> - even if it's to fix a 'typo' - an existing valid instance would no >>> longer validate. >>> >>> Note that the substantive change bar is also applied when changes are >>> made to drafts after public review. If substantive changes have been >>> made, another (shorter) public review is required before the work can >>> be advanced. >>> >>> I hope that helps somewhat. >>> >>> Regards, >>> >>> Mary >>> >>> >>> ___________________________________________________________ >>> Mary P McRae >>> Director, Technical Committee Administration >>> OASIS: Advancing open standards for the information society >>> email: mary.mcrae@oasis-open.org >>> web: www.oasis-open.org >>> phone: 1.603.232.9090 >>> >>> >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: Jacob Westfall [mailto:jake@jpw.biz] >>>> Sent: Wednesday, January 14, 2009 3:30 PM >>>> To: AskTheTAB@lists.oasis-open.org >>>> Subject: [askthetab] errata question >>>> >>>> Hi, >>>> I have a question about what an errata to a specification can >>>> contain. Primarily what changes can be made to a simpleType >>>> enumeration list in a schema under the errata process. Can items in >>>> >> >> >>>> the list be changed perhaps for correction or updated as needs >>>> >> change? >> >>>> Can new items be added to the list, perhaps to correct an oversight? >>>> What would be considered a substantive change? Thanks, >>>> >>>> -- >>>> jake@jpw.biz >>>> -- >>>> >>>> -------------------------------------------------------------------- >>>> - To unsubscribe, e-mail: askthetab-unsubscribe@lists.oasis-open.org >>>> For additional commands, e-mail: askthetab-help@lists.oasis-open.org >>>> >>> --------------------------------------------------------------------- >>> To unsubscribe from this mail list, you must leave the OASIS TC that >>> generates this mail. Follow this link to all your TCs in OASIS at: >>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >>> >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this mail list, you must leave the OASIS TC that >> generates this mail. Follow this link to all your TCs in OASIS at: >> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this mail list, you must leave the OASIS TC that >> generates this mail. Follow this link to all your TCs in OASIS at: >> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >> >> >> -- Patrick Durusau patrick@durusau.net Chair, V1 - US TAG to JTC 1/SC 34 Convener, JTC 1/SC 34/WG 3 (Topic Maps) Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300 Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]