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] Errata: Substantive Schema Change in 15.27.22?


Well, while I agree as to what the OASIS rules say now, isn't it simply 
the case that we need a new set of rules?

Why not use this to illustrate how lame the current errata process is in 
fact and suggest a new set of rules that cover both editorial as well as 
technical errors.

My suggestion would be to have editorial errors, for either committee 
specifications or OASIS standards to be approved only by a TC vote. 
Technical errors would require a TC vote and then a thirty day default 
ballot of the general membership (in other words, if you don't vote, you 
automatically approve). Simply majority wins.

That would put all fixes within a 45 day time frame, assuming we all 
moved at top speed.

True, we would have to define editorial and technical but I suspect we 
could steal something along those lines. All told, less than a page of 
text and a process that would get TC's back into the business of fixing 
their work and out of the check list chase that is the present process.

I can outline a proposed new errata process along the lines I suggest 
above fairly quickly if anyone is interested in pursuing a more 
systematic solution.

Hope you are having a great day!


Dennis E. Hamilton wrote:
> While we are thinking this over prior to the next call, I have some further
> observations:
> 1. The only schema file for ODF 1.0 on the OASIS site has the -treshold
> spelling (although the 1.1 schema has -threshold).  This is not normative,
> but it is something to keep in mind.
> 2. We do not know if translations of the specification carry the -treshold
> and -threshold spellings in literal attribute names and translate otherwise
> when threshold is used in the title and in the prose.  So a developer
> concluding there is a misspelling in the schema may be a little less
> obvious.
> 3. If no ODF 1.0 implementation has ever supported style:wrap="dynamic" we
> would be off the hook.  The one problem is with ODF 1.0 implementations
> evidently still being provided and used in order to be IS 26300 compliant. 
>  - Dennis
> PS: I agree that the easiest way out of this situation is if we could simply
> make the correction in the ODF 1.0 specifications.  Other resolutions (since
> it is changed in 1.1 and we expect that change to continue into 1.2) are far
> messier (unless the feature is still not implemented).
> -----Original Message-----
> From: Michael.Brauer@Sun.COM [mailto:Michael.Brauer@Sun.COM] 
> http://lists.oasis-open.org/archives/office/200809/msg00083.html
> Sent: Wednesday, September 24, 2008 04:49
> To: Doug Mahugh
> Cc: Andreas J. Guelzow; office@lists.oasis-open.org
> Subject: Re: [office] Errata: Substantive Schema Change in 15.27.22?
> [ ... ]
> The section in question reads as follows:
> *****
> Dynamic Wrap Threshold
> The style:wrap-dynamic-threshold attribute is evaluated only if the
> style:wrap attribute has a value of dynamic. It specifies the minimum
> distance between the page or column border and the object for which
> wrapping will be enabled.
> <define name="style-graphic-properties-attlist" combine="interleave">
> 	<optional>
> 		<attribute name="style:wrap-dynamic-treshold">
> 			<ref name="nonNegativeLength"/>
> 		</attribute>
> 	</optional>
> </define>
> ******
> The error report in question is:
> ******
> The first para in 15.27.22 says style:wrap-dynamic-threshold, while
> the schema fragment in this subsection says style:wrap-dynamic-treshold.
> ("h" between "t" and "r" is missing.)
> ******
> We have spelled the attribute name correctly one time (in the
> description), and one time incorrectly (in the schema). The heading also
> says "Threshold". This means that the spelling in fact is inconsistent,
> and the question actually is what implementors reading the specification
> would assume what the name of the attribute is. My personal opinion is
> that implementors notice the inconsistency, assume that it was not our
> intention to misspell the attribute, and implement it with the correct
> spelling. I further would assume that they do not implement a misspelled
> attribute name (if the spelling is correct in the description) without
> notifying us about the issue or asking us what our intention was. I
> therefore think that the correction of the misspelled word is not
> substantive, even if it occurs in the schema. Please note that my
> conclusion would be different if either "treshold" would be a correct
> spelled word, or if we would have misspelled it in the description and
> the heading, too.
> Anyway that is my personal opinion, and I do understand that others come
> to a different conclusion.
> My suggestion for resolving this issue is that we continue to discuss
> this on the mailing list until the end of this week. We may then have a
> small ballot in the TC on Monday whether or not to include this
> resolution in the errata before we conduct the other three votes
> required to start a public review of the draft.
> Best regards
> Michael
> [ ... ]
> ---------------------------------------------------------------------
> 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 
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]