Re: [oiic-formation-discuss] Deliverable: odf-diff?

["Dave Pawson" <dave.pawson@gmail.com>]

AFter a couple of offline emails with Sander,
I think this is getting close to definable (for me),
so I've brought it back on list.
The prime use I see for this is 'friendly' vendors comparing
how things are done.
It will enable a tester to compare applications interaction
with a 'reference' test document.


2008/6/21 Sander Marechal <sander.marechal@tribal-im.com>:

>> So you do mean 'visually' the same?
>
>
> No, I don't mean visually the same. I'll explain better from my last two
> examples:
>
> 2) You have document A with the second word being bolded. It's an automatic
> style called "foo". Document B has the same word bolded with an automatic
> style but it's stylename is "bar". The documents are the same. No user data
> (visually or otherwise) is lost. The spec allows to rename all the automatic
> styles.

Different styles with the same visual effect?
So it is 'visually the same' (but the styles are different).


>
> 3) You have document A with the second word bolded. It's a manual style that
> the user has named "bold-word". Document B looks exactly the same, but the
> stylename for the second word's manual style is "important-word". A diff
> tool should report this as a difference. The stylename is data generated by
> a user and should therefor not be lost.

Again, visually the same, but styles are different.
So these are different XML documents with the same effect on presentation?




> What I mean by two documents being the same or different is "Is it different
> from a user's perspective?" And I don't mean just visually different.

User = viewer, the two examples are 'the same'
User = editor, the stylenames used are different.


> Renaming manual styles does not change the visual look of the document, but
> from a user's perspective the document is different because he can't find
> the "bold-word" style that his boss told him to use.

ouch. That is 3 sources of confusion!
User, editor, now .... the boss!
Keeping him|her out of it, how can we define this one?
A style name change perhaps?
Doc A style is called 'bold-word'
Doc B style is called 'emphasis' ? Would that work?

Would need something to list all the hierarchy of properties which are in effect
on a piece of content? It is possible though.

Do you want to recognise styles with the same effect as 'different'?
(perhaps just reporting the simple xml difference would be enough?
Style foo='font-name, font-size, font-weight....
Style bar='......
So the reader can 'see' the difference in the xml?
(And any visual comparison is left to viewing a screen)



>
> When metadata changes, the visual appearance of the document is the same,
> but a user's external application that parses this metadata will see these
> changes. Metadata is user data, so the diff tool would need to report this.

Simple xml content comparison should be enough here
Doc A modified-date= '....'
Doc B modified-date='....'
Again you can see the difference, make your own choice of what to do.


>
> Changing the order of elements in an unordered set (such as the image
> entries in the manifest) does not affect a user in any way, but an XML diff
> tool will see it as a difference, hence the need for an ODF diff tool.

This is a little different.
Need a comparison of an unordered set, rather than an ordered list.
Also, non xml.



>
> An even better example: application defaults. Take a document A with a line
> of text that has a default style. Application Foo renders it in a Sans-serif
> font at 12pt while application Bar renders it in a Serif font at 14pt. The
> documents look different to a user, but the document itself is the same.
> Nothing in the document that concerns a user has changed.

Good one. Are the defaults kept 'seperate' from the instance?
Sorry I don't know. If they are on your PC then that (IMHO)
is a weakness of the standard. If they are a part of the application,
then it is still wrong from an interop view?

Surely the instance should be standalone?
(No, fonts will be dependent on the machine!)




>
> But, since the TC doesn't make software, it's a moot point.

No, its an issue that needs solving. Somehow.


I was just
> pointing out an existing need from ODF application and tool developers to
> get better conformance and interop.

<grin/> And all of us on this list!



 We'd be able to check if two
> applications produce the same document (given the same data).

And some well defined test environment
  (Now it seems to need to include
*fonts
*default settings (of some sort)
* What else have I missed?

 We could
> integrate it into an application's automated regression test suite. We could
> use it to create a "patch" tool that can merge different versions of the
> same document into one (think ODF editing with multiple users at the same
> time, all users using a different application). As long as they  don't
> change the same portions of a document, you could merge all the changes
> (like in a Wiki. Or plain old software diffd/patches) because changes like
> automates styles renaming get ignored by the diff tool.

With my (current) view it wouldn't be automated. It would need
manual intervention to interpret a list of style information
on the screen?

Sounds useful.

Anyone else got views on this?

Sounds like a good interop test basis, (somewhere between layout perfect
and pixel perfect, but far more practical).

Sander, would you try and describe this as fully as you can and we
can put it up on http://sites.google.com/a/odfiic.org/tc/

Then we need a single sentance to capture the idea of it, as a deliverable?

"Deliverable:
  Specify a tool to facilitate document comparisons when processed by
n vendor products"

Something like that?

regards





-- 
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk