Patrick Durusau <> wrote on 09/06/2011 03:50:47 PM: >
> Rob, >
> From below: > >
> I wouldn't be too concerned about app-to-app rendering differences. That >
> is a different problem. >
> I am not sure if you mean with reference to how (1) changes are
> displayed or (2) in general. >
> If (1): >
> With regard to changes, that certainly is app specific and could be an
> area where apps compete to have useful display of changes. I can think
> of several choices that I would like better than current offerings. >
> If (2): >
> I think we have an opportunity to more specifically say how ODF
> documents should be rendered. Not *how* they get rendered but how they
> should appear. Users see that as interoperability and to some degree
> rightly so. They intend for the same input (the ODF documents) to have
> the same result when processed by a conforming application with the same
> capabilities. That's really not unreasonable. How far we can go towards
> that goal with every release remains to be seen. >
> Hopefully applications are going to "stay ahead" of the markup in some
> ways so that user demands are in part driving the XML that we develop to
> encode their needs.
> I meant #2. I'm not saying that #2 is not important or that we should do it. I just mean that that is an orthogonal question to change tracking. For example I could have a document with line-style="exquisite" and then another app edits the document and has the user change the doc so it now is saved as: line-style="refined" This can be change tracked even if the spec is deficient in saying how "refined" and "exquisite" should be rendered. In other words, we cannot assume that undefined things are identical. But it is possible for some things, including undefined things, to be defined to be equivalent. If that make sense.
-Rob
> Hope you are having a great day! >
> Patrick >
> On 9/6/2011 12:00 PM, wrote: > > "Dennis E. Hamilton"<> wrote on 09/06/2011 >
> 09:45:16 AM: > > > >> See Rob's explanation if that makes more sense. > >> > >> At this point in the life of ODF, there is no way that the ODF TC > >> can undertake define when two ODF representations are for the same >
> documents. >
> We can start with Canonical XML [1]. From there we could easily define >
> canonicalization of inter-document references, e.g., styles. We could >
> define canonical ordering of items in ZIP, etc. So there are some things >
> we could define. But it is not clear how far up the semantic chain we >
> would take it. For example, there is some freedom where we put style >
> definitions. Is that a "real" difference? It is if we define it to be. > > >
> I wouldn't be too concerned about app-to-app rendering differences. That >
> is a different problem. But if doc 1 has a blue rectangle and doc 2 has a >
> green oval, then the docs are different, even if some screwed up app fails >
> to render them correctly. This is true even if the spec doesn't even >
> define how they should be rendered. > > > > [1]: http://www.w3.org/TR/xml-c14n > > > >> And there are comparison tools that work at the document (not XML > >> level). OpenOffice.org has one built in. They've been in all > >> flavors of Microsoft Office for years. (I imagine they might even > >> compare a .doc and a .docx, who knows?!). They make it look like > >> one was produced from the other (user choice) by change tracking. > >> Imagine that! > >> > >>
- Dennis > >> > >>
