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

[Robin LaFontaine <robin.lafontaine@deltaxml.com>]

Answers inline below.
Robin

On 17/10/2011 21:52, John Haug wrote:

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?

These are independent, I believe. I cannot think of a reason why a choice for one would dictate a choice for the other, though it might influence it.

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.

A doc-level property might be useful, though if ODF always required one method then a reader could always expect/trust that it would be that way and only apply a transform if it preferred it the other way. I think a doc would be considered invalid if the doc-level property was wrong.

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?

There is quite a lot of work going on (in the XSLT community) to enable streaming XSLT so the doc does not all need to be in memory. That said, Saxon uses tree representation which is considerably smaller than DOM. I am not sure at this stage if the XSLT could be streamed in this particular case, it depends on the transformation. However moving info from cached to in-situ would likely not be streamable. FYI we use a lot of pipelined XSLT transformations and they are now pretty efficient, though of course streaming is faster.

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 



---------------------------------------------------------------------
To unsubscribe, e-mail: office-collab-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: office-collab-help@lists.oasis-open.org

-- 
-- -----------------------------------------------------------------
Robin La Fontaine, Director, DeltaXML Ltd  "Change control for XML"
T: +44 1684 592 144  E: robin.lafontaine@deltaxml.com      
http://www.deltaxml.com      
Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK