OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office message

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

Subject: Re: [office] Re: #6.8 - Errata Review - "In-passing errors"


In theory I don't disagree with your position on errors in the text and 
don't want you to have the impression that I do.

As a practical matter, however, errata have to be bounded by those 
reported by someone, else how would we know where to stop? One position 
would be that we should create "errata" that when applied would result 
in ODF 1.2. That is certainly possible in theory but I would not want to 
volunteer for the task.

The purpose of this errata is to fulfill our maintenance obligations 
that OASIS undertook when it submitted ODF 1.0 2nd edition to ISO. There 
are a variety of opinions about the process we have or have not followed 
and I don't want to get diverted into that discussion here.

Suffice it to say that this set of errata was created to answer the 
Japanese "defect" report which I referenced earlier today. And yes, 
there were a number of errors in my latest draft that you caught and I 
am very grateful for the hard work.

Yes, the ODF TC needs a vigorous discussion of errata processes, how 
long we will even answer questions about prior versions, etc.

However, my impression is that while ODF is of a great deal of interest 
to many parties, the TC doesn't have unlimited resources and so I 
suspect that at some point we are going to decline to maintain earlier 
versions of the ODF standard. That is just a guess on my part but I 
think it is probably accurate.

Hope you are having a great day!


PS: I have been cross-checking against your checks, plus against the 
Japanese errata and both the ODF 1.0 and ISO 26300 text so I am hopeful 
that the version I file tonight will be fairly clean.

Dennis E. Hamilton wrote:
> Patrick,
> I was not consulting the defect report.  I just happened to see, while
> trying to match up the lines, that there was this other line that had
> exactly the same problem. (I ran into that line by mistake while checking
> the existing errata items and it took extra effort to be sure which were the
> correct places to apply the existing errata.) 
> So I am pointing out this other place in the same table.  In one sense it is
> the same defect, and I am not so literal about scope (since as a reviewer of
> the errata as it is disseminated, I have no idea about that - the scope
> restriction is not in evidence).
>  - Dennis
> PS: For me, specifications are like software even though in prose.  That,
> together with the prospect of non-native English readers and translators for
> other languages, requires extra care.  Handling comments and defect/incident
> reports (again, for me) is like dealing with bugs and usability hiccups.
> There is what is reported, which may be a symptom, there is the underlying
> defect, which needs to be figured out, and then there is finding the places
> where the defect is to be remedied.  Asking where else the defect may be
> manifest is a natural question when dealing with software and
> specifications.  That might be too complicated for a simple erratum/patch
> and broader remedies are deferred to a new release, but if one jumps out in
> your face, my tendency is to nip that one off too.  Why leave it to trip
> people up and having to be found again later when it is in our hot little
> hands right now.  
> There is also the small matter that, to outsiders, having no knowledge of
> and concern for "the scope," seeing an obvious defect be incompletely
> corrected will reflect badly on the TC and leave doubts about where else we
> are careless about this (from an external perspective). 
> In this particular case, if we don't make the change now (arguing that it is
> in scope because it is the same defect and it will trip people up to see it
> overlooked), it is at least captured now and can go on a growing list of
> items for future errata.  Unless ODF 1.0 is declared obsolete or supplanted,
> I suspect that another errata document is quite likely. 
> -----Original Message-----
> From: Patrick Durusau [mailto:patrick@durusau.net] 
> http://lists.oasis-open.org/archives/office/200809/msg00030.html
> Sent: Monday, September 15, 2008 08:39
> To: dennis.hamilton@acm.org
> Cc: office@lists.oasis-open.org
> Subject: [office] Re: #6.8 - Errata Review
> Dennis,
> Another question:
> Dennis E. Hamilton wrote:
> http://lists.oasis-open.org/archives/office/200809/msg00024.html
> <snip>
>>           ODF 1.0     IS 26300
>> Section   page line   page line
> <snip>
>> *9.5.3*  *330* *27*  *334* *29*  [under "T" *** missed ***, same as B and
> V]
> When you say "missed," do you mean not in the Japanese defect report?
> If so, why would it appear in this errata document? (Note I am not 
> disagreeing an error exists, but asking about the scope of this 
> particular errata document.)
> Hope you are having a great day!
> Patrick
> [ ... ]

Patrick Durusau
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]