Re: [office] "deprecation"

[Michael Brauer - Sun Germany - ham02 - Hamburg <Michael.Brauer@Sun.COM>]

Hi Florian,

thank you very much for these clarifications.

Florian Reuter wrote:
> Hi,
> 
> I used the word "deprecation" in my list, which seemed to cause some bad feelings. Please let me explain:
> 
> I made the point
> * declare sub tables as deprecated
> in my suggestion list, because I really think that row-span and col-span method is better suited to express merging(http://www.oasis-open.org/archives/office/200611/msg00050.html). I seem to share this thought with Richard Schwerdtfeger(http://www.oasis-open.org/archives/office-accessibility/200608/msg00031.html) who has concerns about sub tables regarding accessibility.

Row- and Colspan attributes are already supported by ODF. If it has 
advantages to use them instead of sub-tables for accessibility reasons, 
then we may state that in the accessibility guidelines, or maybe even in 
specification, but this does not provide a reason to deprecate the 
feature of seem-less sub-tables in general.

> 
> I also made the point
> * declare the style:next-style-name attribute of master-page declarations as deprecated.
> In my opinion this feature is bad for accessibility and interoperability too. I’m happy to discuss this.

Can you please explain why you believe that this feature is bad for 
accessibility. Regarding the deprecation of features for 
interoperability reasons, my comments to your suggestion list are still 
valid.

In general, I think the style:next-style-name attribute is a very 
powerful and useful feature, that allows a very flexible assignment of 
page styles to text flows. We should not deprecate that.

> 
> The following statement was made, because I would like to get rid of a redundancy:
> * declare style:list-level-properties/@text:space-before as deprecated. Effect can be achieved with paragraph indent.

Well, using the paragraph indent rather than the text:space-before 
attribute in my point of view means that the indentation attributes for 
  lists are not at a single place any longer, but distributed to list 
and to paragraph styles. Actually, I don't think that this makes list 
formatting easier.

> 
> So I think the points have a relationship to MOOX interop, but they are valid in itself.
> 
> 
> The "discourage" statement regarding nested framed, text:sections, fo:break-after and fo:margin was meant as an _information_ to the TC which features cause problems. What the TC makes of this _information_ is up to the TC.

Okay. If that's the case, then I take this as an information. However, I 
still think we should not deprecate or discourage the use of features 
for the reason that they are not supported by other file formats. 
Especially not if we know that these features are in use by OpenDocument 
applications.

> However please to not spin political issues out of technical information in a technical committee. If every time I (or someone else) who posts information get’s confronted with politics (like TC45, OOo, …) the TCs work will get harmed a lot.
> 
> For questions regarding Novell, OASIS, ECMA I would like to point you to Alan Clark (aclark@novell.com). For comments like "ahh, no you’re wrong, actually text:sections can be mapped to MS sections back and force" please contact me immediately.

I personally don't know the details about this issue, but if OOX 
sections cannot be mapped to OpenDocument completely, then we may 
consider to enhance OpenDocument so that this becomes possible. If 
OpenDocument's text:sections cannot be  mapped to OOX, then the 
technical correct way to resolve this in my point of view would be to 
enhance OOX, but this is not within the scope of our TC's charter.

> 
> ~Florian
> 

Best regards

Michael