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

[Sander Marechal <sander.marechal@tribal-im.com>]

Dave Pawson wrote:
> 2008/6/20 Sander Marechal <sander.marechal@tribal-im.com>:
> 
>>> In which case your interpretation of 'different' needs clarity
>>> Sander?
>> Most definitely. I'm a developer, a tech person. I'm not much of a 
>> wordsmith. If I can get my point across then I hope someone else
>> can run with it and write a "proper" definition :-)
> 
> I'm still not clear on your definition/interpretation of 'different'.

Functionally equivalent? The only things that can differ are things that 
the spec implies can be different? I was hoping that my examples would 
make clear what I meant with "different".

>> You're quite right that metadata changes
>> should show as well. For the load&save example I gave, the only
>> difference between the document should probably be "last edited" or
>> "last saved" or "last edited with application X" fields. To give a
>> better example:
> 
> So that would be the {infoset or something} is the same, except 
> xpathA/text() is different xpathB/@Y is different. etc.

I don't understand you here. Sorry. What I mean was, that an ODF-diff 
tool should report that the "last modified by" field is different. It's 
up to the person running the tool to realize that this field is supposed 
to be different when you load and save a document.

>> Someone on this list mentioned that an application can rename all
>> of the automatic styles however it feels like when it saves a file.
>> An ODF diff tool should take this into account when comparing the
>> two files.
> 
> Better. *ignore all style(presentation) values* and run an xml diff.
> 
> That would be something like an interchange profile perhaps? Is that
> what you want?

No. If you ignore all style values, two documents would still be the 
same if one document has some word bolded, while the other one does not.

Example 1:
Document A has it's second word bolded and document B not. That's a 
difference that should be reported.

Example 2:
Both document A and B have it's second word bolded. The bold style is an 
automatically generated style. In doc A the style name is "foo" and in 
doc B the style name is "bar". But both "foo" and "bar" describe the 
exact same thing (e.g. Default + some fo:font-weight). They are the same 
and ODF-diff should say nothing.

Example 3:
Same as example 2 but now it's not an automatic style but a manually 
made style. Now the ODF-diff should report it as a difference. After 
all, the syle name was specified by the user and he has (probably) made 
care to pick a certain style name.

>> Another example: The order of elements in the manifest.xml doesn't
>> matter. As long as all the files are referenced.
> 
> Ah. You need to check with the spec on that, but that's clear. The
> file list is a set (order unimportant)

It's an example I made up on the spot. I'm not 100% sure the spec says 
anything about the order of referencing images in the manifest, but I 
don't believe it does :-)

 > Who else would it help, who is also a 'customer' of the TCs output?

I thought the TC's output was (umong others) the ODF application 
developers? Other users for this tool are the TC itself. How are you 
ever going to do conformance testing or an ACID test if you can't even 
tell if two ODF documents are the same? Being able to tell if two 
"things" are the same seems to me a pretty basic thing in any 
testing/conformance environment.

My thoughts are that (A) application developers and tookit developers 
could really use such a tool. (B) The TC is most likely going to have to 
develop something like this either as part of one of the other 
deliverables or just to internally test whatever they're writing and 
developing. For example, as part of the set of atomic feature test 
documents. (C) It's very hard to go through the spec and build such 
tool. It requires intimate knowledge of the spec. Since the TC is most 
likely going to do the leg-work for this anyway (see B) we may as well 
put it on the list of deliverables so that everyone can profit it.

-- 
Sander Marechal