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


Help: OASIS Mailing Lists Help | MarkMail Help

oiic-formation-discuss message

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

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

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'.

>>  For example: I could change the
>>> name of a style on a paragraph and also change that name in the
>>> styles.xml
>>> and functionally, the two documents should still be the same even though
>>> an
>>> XML diff tool says they're different.
>> <chuckles/> Are you talking about 'visually' different?
> No, not just visually. 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,
    xpathA/text() is different
    xpathB/@Y is different.

> 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?

> 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)

>> Probably, if you can define it.
> That's going to be tough I fear :-( It will be hard work to figure out what
> things can change in an ODF file that do not have any impact on anything.
> That something the TC should do, not us. That's why I'd like to add such a
> deliverable. It's mainly a mattter of how you describe it.

Sorry, I disagree. I haven't heard any rationale for wanting such a comparison
other than for implementers at a meeting? To me that isn't enough
to put it in the list of deliverables.

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


Dave Pawson

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