[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] "deprecation"
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]