Rob,
On Tue, 2010-09-21 at 15:59 -0400, wrote:
> Patrick Durusau <> wrote on 09/21/2010 03:34:29 PM:
>
<snip>
> It is a non-goal for me to make everyone happy. It is clear that for
> every person who will say, "Why did you approve ODF 1.2 without X?" there
> is another person already asking, "Why is taking you so long to complete
> ODF 1.2 so we can have Y?"
>
>
True, but "we don't have to please everyone" isn't a mantra that is
going to win many friends.
Maybe what we do in practice but better to appear gracious and
interested in feature requests.
And having a future schedule when features will appear would not be a
bad thing.
> > Before any implementors work on "complete" change tracking, I would
> > really like to see RDF based metadata support.
> >
>
> Have you seen the work in KOffice and Freoffice? We're starting to see
> implementations.
>
No, but I will take a look. Thanks!
Hope you are having a great day!
Patrick
> Regards,
>
> -Rob
>
> > Bringing intelligence to "dumb" documents is like buying foreign
> > language dictionaries in hopes a class will learn a foreign language. A
> > few may, but very few.
> >
> > A smarter web needs to start with smarter documents. ODF/RDF metadata is
> > a step in that direction.
> >
> > Hope you are having a great day!
> >
> > Patrick
> >
> > On Tue, 2010-09-21 at 13:29 -0400, wrote:
> > > A few thoughts on change tracking.
> > >
> > > What would make this feature "complete"? I think change tracking is
> > > complete if an application can record any change to the end-user
> semantics
> > > of the document. This includes things like changing the visible
> content
> > > of the document, but also changing the metadata. It does not include
> > > changes that have no end-user semantic value, e.g., changing an xml:id
> or
> > > automatic style name to a different value, provided the referential
> > > integrity is maintained.
> > >
> > > I should be able to take two arbitrary ODF documents of the same type,
> say
> > > text documents A and B, generate a diff of them and encoded that diff
> of A
> > > to B as change tracks on A, such that when I accept all tracked
> changes in
> > > A I get something semantically equivalent to B.
> > >
> > > Given that as a goal, I think we need to get it out of our heads that
> any
> > > standard or implementation does change tracking completely today.
> > > Everything I can find has some notable areas of missing functionality.
> > >
> > > Aside from the issues already noted in JIRA, consider:
> > >
> > > - It is possible for a named style to change its definition, without
> > > changing anything in content.xml. For example, I could have a style
> > > called "hidden" that is defined as white text on a white background,
> and
> > > then unhide it later by merely redefining the definition in
> styles.xml.
> > > How is that tracked? MS Word does this, and in the UI appears to hint
>
> > > that it is a change to the document as-a-whole rather than any
> particular
> > > content. This seems reasonable.
> > >
> > > - It is possible to replace an image file with an identically named
> image
> > > file but with different content. How is that tracked?
> > >
> > > - Similarly, for any object embedding, OLE or whatever, how are
> changes
> > > tracked? (MS Word doesn't seem to track these changes)
> > >
> > > - And what about MathML, a special kind of object in ODF?
> > >
> > > - And what about sub-documents?
> > >
> > > - Or RDF XML metadata?
> > >
> > > - Or Changes to the manifest, such as adding a new resource, not
> > > necessarily references from content.xml
> > >
> > > - And what about presentation files, which appears to lack support
> even in
> > > OOXML?
> > >
> > > So change tracking, if you want to be complete, needs to deal with
> changes
> > > at the packaging level, in all of the defined XML's, as well as
> changes in
> > > linked resources, such as jpeg images and RDF XML. As far as I can
> tell,
> > > no application and no standard does complete change tracking. So I
> > > suggest we don't take it as a last-minute goal for ODF 1.2 to achieve
> > > completeness there.
> > >
> > > However, inability to do everything is not an excuse not to do
> nothing. If
> > > we can extend the current change tracking approach to some of the more
>
> > > commonly-reported pain points, like change tracking if table row
> > > deletions, etc., then this would be good. But I'd propose that before
> we
> > > move to a new and incompatible representation of change tracking that
> we
> > > sit down and work through the entire semantic content of an ODF
> document
> > > and ensure that we're using an approach that is capable of recording
> > > changes across the entire range of possible document edits. This is
> > > important, and worth doing, but worth doing right. The proposal
> submitted
> > > via the comment list appears to be an excellent start, but we need to
> > > expand it to cover some of these other use cases, if we want to claim
> > > completeness.
> > >
> > > Regards,
> > >
> > > -Rob
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe from this mail list, you must leave the OASIS TC that
> > > generates this mail. Follow this link to all your TCs in OASIS at:
> > > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the OASIS TC that
> > generates this mail. Follow this link to all your TCs in OASIS at:
> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> >
>
