Re: [office] Errata: Substantive Schema Change in 15.27.22?

[Patrick Durusau <patrick@durusau.net>]

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)