> I cannot think of a reason why a choice for one would dictate a choice for the other, though it might influence it.
It feels to me a bit inconsistent to have similar material stored in different ways and the availability of such an option would make it that much more likely
an implementation will always have to run an XSLT. At the least, having to handle multiple options increases the size of the test matrix. I suspect the response is “if ODF always required one method”.
I think that’s a pretty fundamental question for the SC to consider if it adopted this approach, as it could have the effect of implying the use of particular technologies (and precluding others) to handle otherwise regular XML.
On that thought…
> 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.
I think I am viewing this from a similar perspective as Andreas noted (above). Is raising the question of various choices an open design issue for discussion
to settle on a single answer or is the idea to have a generalized XML change tracking scheme that could be picked up by ODF using a to-be-determined profile? The latter seems it would be out of scope for the ODF TC – it sounds more like a standard adopting
by reference an externally developed/adopted/standardized technology. If it’s just an open design question, that makes more sense as we still have no small amount of work to do regardless of which directions we take.
John
From: office-collab@lists.oasis-open.org [mailto:office-collab@lists.oasis-open.org]
On Behalf Of Robin LaFontaine
Sent: Tuesday, October 18, 2011 9:53 AM
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
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
--------------------------------------------------------------------- To unsubscribe, e-mail:
office-collab-unsubscribe@lists.oasis-open.org For additional commands, e-mail:
office-collab-help@lists.oasis-open.org