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] 15.27.22 - treshold - > threshold

I think there are actually three choices with regard to 15.27.22 and the use
of style:wrap-dynamic-treshold.

1. My favorite: Correct the *text* (not the schema) to use
style:wrap-dynamic-treshold in the one place where
style:wrap-dynamic-threshold is used as the specific attribute name.
Option: A note that this attribute will be deprecated in favor of a
different spelling in a future release.

2. Second choice: Do not change ODF 1.0 although this leaves the
defect-report response in limbo, apart from saying this will be changed in a
future version of the ODF Standard.  (I don't know how to appeal to 1.1 at
the ISO level.)

3. Third choice: Make the change to the schema as was originally proposed.
We run into problems with current OASIS errata rules here, although it would
appear that this attribute (by either name) is not implemented in any ODF
1.0 processor and no ODF 1.0 documents that use this attribute are in the
wild as we say.

Why do I favor (1)?  For these reasons:

a. It is not actually more costly than (3) because there don't appear to be
any implementations that are disturbed either way.

b. It honors the policy that the schema is definitive and, since there is no
inconsistency with -treshold in the schema, there is no schema defect to

c. It emphasizes that there is a schema spelling that must be noticed if
this attribute is implemented in ODF 1.0 (at least among those of us where
"threshold" is a recognized word and the attribute may be misread as using
that word). 

d. It establishes our earnest commitment to interoperability and
preservation of documents in ODF formats.  Not that we are committed to
preserving every slip-up forever, but that we are going to be disciplined,
transparent, and systematic in how we deal with these matters.

e. It gives us practice at this at an early point before we have bigger
problems to deal with of this kind. I know that is not a very good argument.
It is how we train ourselves to avoid bigger mistakes.  If it would up to
me, and it was my specification, I would find it easy to make this choice
(although it was not in any way obvious to me until we had all of the
discussion about this little problem).  I understand that there is more work
in now carrying out the intentional deprecation, if we choose to do so.  Oh,
so that leaves

f. We can, if we choose, not do anything further and simply memorialize
-treshold for this attribute.  That is, the default case is straightforward
(although we need to look at aligning 1.1 and especially 1.2).

 - Dennis

 - - - - - - - - - - - - -

g. I should point out that we know from the 1.1 work that there are other
odd spellings (likely to have been typos) in the schema.  We will have to
look at them individually to see whether this approach applies or there are
more difficult problems.  There will be further lessons there.  Not every
case may be this "easy."

-----Original Message-----
From: Michael.Brauer@Sun.COM [mailto:Michael.Brauer@Sun.COM] 
Sent: Monday, September 29, 2008 05:14
To: Patrick Durusau
Cc: office@lists.oasis-open.org
Subject: Re: [office] 15.27.22 - treshold - > threshold


On 09/28/08 11:10 PM, Patrick Durusau wrote:
> Michael,
> Starting with the easy one first. ;-)
>> However, since we received the error report for 15.27.22 already and 
>> resolved it already by making a change in ODF 1.1 although we could 
>> have made a change in ODF 1.0 2nd edition, I think it is valid to 
>> refer to that resolution, rather than reverting that resolution. 
> Just a question to clarify:
> Do you say: Correct ODF 1.0 2nd Edition Schema from 
> style:wrap-dynamic-treshold to style:wrap-dynamic-threshold based on our 
> earlier decision at:
> http://lists.oasis-open.org/archives/office/200605/msg00098.html

If, we want to correct this in the errata, then adopting what we have
decided for ODF 1.1 seems to be the only reasonable option to me.

However, the decision we made when we discussed ODF 1.0 2nd edition was
to not correct this error in that version, but in ODF 1.1 only. We
therefore may also just refer to this decision and omit the
correction in the errata.

I have no strong preference for either options, and would like to 
suggest that we simply check in the call which of the two options gets a 
majority in the TC.

Best regards


Michael Brauer, Technical Architect Software Engineering
Sun Microsystems GmbH             Nagelsweg 55
D-20097 Hamburg, Germany          michael.brauer@sun.com
http://sun.com/staroffice         +49 40 23646 500

Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1,
	   D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering

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:

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