W3C home > Mailing lists > Public > public-change@w3.org > March 2013

Re: Fwd: A sort of synthesis

From: Claudius Teodorescu <claudius.teodorescu@gmail.com>
Date: Mon, 11 Mar 2013 18:19:31 +0200
Message-ID: <CAPTZ0Vz4qNqmgr-R4BTBfcZ64PK-w9z-qzti3HJXshbYOXneMg@mail.gmail.com>
To: Randall Leeds <randall.leeds@gmail.com>
Cc: liam@w3.org, dennis.hamilton@acm.org, "public-change@w3.org" <public-change@w3.org>
A good representation of changes can be in or out of the respective

For out case, doesn't seem to pose so many difficulties.

As to the inside XML document case ... what if we can design something we
can call "change tracking instructions", in order to graciously store
metadata about changes inside the document?


P. S. For Dennis E. Hamilton: I would specify the tracked changes by using

On Sat, Mar 9, 2013 at 6:31 AM, Randall Leeds <randall.leeds@gmail.com>wrote:

> On Fri, Mar 8, 2013 at 7:43 PM, Liam R E Quin <liam@w3.org> wrote:
> > On Fri, 2013-03-08 at 19:01 -0800, Randall Leeds wrote:
> >> On Fri, Mar 8, 2013 at 12:40 PM, Dennis E. Hamilton
> >> <dennis.hamilton@acm.org> wrote:
> >> > I think the injection of externally-held change-tracking is an
> interesting situation.
> >> >
> >> > Processors that attempt to merge the information in some way will
> have to be resilient with respect to situations where the subject XML
> document is not consistent with the one the changes were introduced for.
> >> >
> >> > It seems to me that the key issue is how the external material
> specifies where the tracked changes apply in the subject XML document.
>  Perhaps the closest highly-rigorous case is external application of XML
> Digital signatures to (parts of) an XML document.
> >>
> >> I would recommend against attempting to answer this question since
> > [...]
> >> "it's a pretty hard problem".
> > Having previously shipped a product that could do external annotations
> > pretty darned well even in the face of changes to the markup (in an SGML
> > world, not HTML), and knowing the same methods would work fine for XML,
> > I'd say it's an adequately solvable problem.
> >
> > If we don't try to do anything because it might be too hard to do
> > perfectly or because someone else is trying to do something vaguely
> > similar somewhere else there wouldn't be a Web today.
> Sure. I'm wishing to promote collaboration, though. My recommendation
> is just to avoid complex specifications for merging. If "resilient"
> means recommending that processors not choke on bad input, then I
> agree with Dennis. I believe representing the changes themselves,
> though, is more central to the value proposition of this group.
> Therefore, the specifics of subject referencing should be kept as
> simple as possible.
>  I was prematurely alarmist. I'm optimistic about our ability to
> produce sane and succinct recommendations for external storage of
> changes.
Received on Monday, 11 March 2013 16:19:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:11:22 UTC