[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?
Michael, Michael Brauer - Sun Germany - ham02 - Hamburg wrote: > Hi all, > > I did some research, and noticed that we by intention did not include > this schema change into ODF 1.0 2nd edition, but ODF 1.1 only: > > http://lists.oasis-open.org/archives/office/200605/msg00098.html > > I therefore suggest that we do not revert this decision, but simply > omit that change in the errata. > OK, but you say in that post: > I'm currently preparing a new draft which corrects the spelling errors, > except those in the schema. While the spelling errors in the schema are clear > spelling errors, too, I believe the best way to correct them is to add > correct spelled attributes/attribute values to the schema for a 1.1, and to > declare the misspelled ones to be depricated. That would imply to me that *if* we were to fix this in ODF 1.0 second edition, that we would add the corrected attribute and deprecate the mis-spelled one. Yes? Just checking to see if we were to fix it, how you are reading our prior action. Hope you are having a great day! Patrick > Best regards > > Michael > > > > On 09/25/08 03:19, Patrick Durusau wrote: >> Dennis, >> >> 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! >> >> Patrick >> >> 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 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]