[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, except xpathA/text() is different xpathB/@Y is different. etc. > > 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? regards -- Dave Pawson XSLT XSL-FO FAQ. http://www.dpawson.co.uk
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]