OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-collab message

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


Subject: Re: [office-collab] Format content - target September 26 2012


I agree with you on this, Oliver-Rainer. We had big problems in comparing documents due to automatic styles (I am sure you can imagine the problem!). Some applications 'rationalize' or 'normalize' the styles so there is no duplication, others do not. We had to pre-process the automatic styles to put them in a canonical form before doing a comparison otherwise we found a lot changes that were not real changes.

I agree with Patrick when he says:
I would prefer to simplify the style mechanisms prior to defining change
tracking for them.
And this could be done by adding some rules about normalization (no duplicates allowed in automatic styles) or better still having a different representation.

Robin
On 21/09/2012 14:57, Oliver-Rainer Wittmann wrote:
Hi,
Greetings!

Your daily dose of CT issues!

The ECT proposal notes that ODF 1.2 does not track style changes, so the
first question for the SC:

1) Do we accept that style changes should be tracked?

I am assuming yes but I think we need to be clear on that point because
it brings up:

What changes we want to make to the style mechanisms?

Now we have common, automatic, master (just from memory).

My view on automatic styles and changes to them is the following:
- An automatic style represents more or less the attributes set at a
certain "component". E.g., the formatting attributes of a paragraph.
- If the automatic styles of two or more "components" are the same, the
automatic style only occurs once in the ODF document and is referenced by
all "components" which have the corresponding attributes in common.
- Thus, a change to an automatic style does not really exist for me.
- If a change of the attributes of a certain "component" occurs - for me -
it means that it applies a another automatic style.
Thus, a change to an automatic style more or less does not happen in my
view.
What is happening in my view is the creation of a new automatic style and
the change of which automatic style is referenced.

My view on common styles and changes to them is the following:
- Changes to common styles happen ;-)
- Such a change could be:
-- change of the value of an attribute
-- insertion/deletion of an attribute
-- insertion/deletion of a child element.


I would prefer to simplify the style mechanisms prior to defining change
tracking for them.

Hope everyone is having a great week!

Patrick

Mit freundlichen Grüßen / Best regards
Oliver-Rainer Wittmann

--
Advisory Software Engineer
-------------------------------------------------------------------------------------------------------------------------------------------

IBM Deutschland
Beim Strohhause 17
20097 Hamburg
Phone: +49-40-6389-1415
E-Mail: orwitt@de.ibm.com
-------------------------------------------------------------------------------------------------------------------------------------------

IBM Deutschland Research & Development GmbH / Vorsitzende des
Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart,
HRB 243294


---------------------------------------------------------------------
To unsubscribe, e-mail: office-collab-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: office-collab-help@lists.oasis-open.org


-- 
-- -----------------------------------------------------------------
Robin La Fontaine, Director, DeltaXML Ltd  "Experts in information change"
T: +44 1684 592 144  E: robin.lafontaine@deltaxml.com      
http://www.deltaxml.com      
Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK


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