RE: [office-collab] Groups - Proposal for generic representation of tracked changes for ODF (generic-ct-proposalV5-updates.odt) uploaded

[John Haug <johnhaug@exchange.microsoft.com>]

I apologize for my lateness in commenting.  It's taken quite a while to catch up from missing September.  A few questions...

In section 3 Definitions, #15 (caching deleted content) and #16 (caching attribute changes) each say that only one of the two methods (in situ vs. cached elsewhere) must be chosen.  Can those choices be made independently or is the choice made once for both?

Would an implementation need to apply an XSLT on every document load or parse the document before determining whether one is needed?  There is no provision for a doc-level property indicating what storage choice was made and thus whether an implementation really needs to apply the XSLT.  Of course, load code ought not blindly trust such a property anyway.

What about SAX parsers?  I believe applying an XSLT requires having the entire XML document in memory, which essentially implies DOM, or at least something DOM-like.  If so, wouldn't that preclude an implementation from taking advantage of the performance and memory benefits of SAX streamed reading?

Thanks,
John

-----Original Message-----
From: Andreas J. Guelzow [mailto:andreas.guelzow@concordia.ab.ca] 
Sent: Thursday, September 15, 2011 4:20 PM
To: office-collab@lists.oasis-open.org
Subject: Re: [office-collab] Groups - Proposal for generic representation of tracked changes for ODF (generic-ct-proposalV5-updates.odt) uploaded

Hi Robin,

It hadn't occurred to me that with "application" you mean "format" so that ODF would be one application of some more general GCT. 
As far as I am concerned this subcommittee deals with ODF. So I read the proposal within the context of ODF and if there are choices given for the writer I would assume that these choices are intended to be available inside ODF. Perhaps we need a translation of the GCT proposal to ODF.

On Wed, 2011-09-14 at 02:25 -0600, Robin LaFontaine wrote:
> On 13/09/2011 15:42, Andreas J. Guelzow wrote: 
> > -------------
> > While having delta:removed-content allows the deleted content to 
> > place elsewhere, it still allows it to be retained in situ. This 
> > does not seem to resolve the issue that a 1.2 or earlier 
> > implementation when encountering this element needs to understand it 
> > to be able to ignore the element content.
> I am not sure I understand your comment. I would not envisage a 1.2 or 
> earlier implementation could read GCT at all, nor could it read most 
> of ECT either. In the same way 1.1 reader cannot understand all of 
> 1.2.

Of course an ODF 1.2 consumer would not be able to interpret the GCT elements within an ODF 1.3 file. But if that consumer views the GCT elements inside the ODF 1.3 file as foreign elements, I would hope that the result would make some sense. So character content should not remain in-situ but moved somewhere else.

Andreas  

--
Andreas J. Guelzow, PhD, FTICA
Concordia University College of Alberta


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