You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@corinthia.apache.org by "Dennis E. Hamilton" <or...@apache.org> on 2015/03/11 16:43:19 UTC
RE: [CONF] Corinthia > ODF
Nice catch! That is a 2005 book and it has some deviations to watch out for. It is based on ODF 1.0 and also rather wedded to OpenOffice 1.9 (in contrast with the 3.x and now 4.x series).
I split up General Information to add a section on processing resources after the information about the standards, and include OASIS OpenDocument Essentials in it. [That assumes that Confluence does not continue to be spinning on my attempt to commit the changes.]
Sorry for top posting in this manner. But these HTML-formatted posts are difficult to do anything else with. So long as I am given HTML formatting, I will be top posting.
- Dennis
From: Gabriela Gibson (Confluence) [mailto:confluence@apache.org]
Sent: Wednesday, March 11, 2015 05:57
To: orcmid@apache.org
Subject: [CONF] Corinthia > ODF
Gabriela Gibson <https://cwiki.apache.org/%20%20%20%20https:/cwiki.apache.org/confluence/display/~gbg%20> edited the page:
<https://cwiki.apache.org/confluence/display/Corinthia/ODF> ODF
Comment: Added links to OASIS OpenDocument Essentials book.
General Information
An introductory book can be obtained here: OASIS OpenDocument Essentials <http://books.evc-cit.info/odbook/book.html> HTML <http://books.evc-cit.info/OD_Essentials.pdf> PDF
...
View Online <https://cwiki.apache.org/confluence/display/Corinthia/ODF> · View Changes <https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=53739751&revisedVersion=5&originalVersion=4> · Add Comment <https://cwiki.apache.org/confluence/display/Corinthia/ODF?showComments=true&showCommentArea=true#addcomment>
Stop watching page <https://cwiki.apache.org/confluence/users/removepagenotification.action?pageId=53739751> · Manage Notifications <https://cwiki.apache.org/confluence/users/editmyemailsettings.action>
This message was sent by <http://www.atlassian.com/software/confluence> Atlassian Confluence 5.0.3, <http://www.atlassian.com/software/confluence/overview/team-collaboration-software?utm_source=email-footer> Team Collaboration Software
Re: [CONF] Corinthia > ODF
Posted by Peter Kelly <pm...@apache.org>.
> On 12 Mar 2015, at 6:42 am, Gabriela Gibson <ga...@gmail.com> wrote:
>
> I know of at least one secretary who in 2000 was the only person in the
> entire university to still use Wordstar, because 'this is what she was used
> to', and systems (and everyone else) humoured her.
>
> So, there will be occasions where people will want to be able to use a
> legacy program, because it makes life easier for them, or perhaps, an old
> machine is all they can afford, or they simply don't want to enter upgrade
> hell.
My response to this is the same as if the question were should we support Netscape 4.0 :)
—
Dr Peter M. Kelly
pmkelly@apache.org
PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
Re: [CONF] Corinthia > ODF
Posted by jan i <ja...@apache.org>.
On 12 March 2015 at 17:39, Dennis E. Hamilton <de...@acm.org>
wrote:
> The TL;DR on Gabriela's questions:
>
> 1. I am not confident that the Corinthia model can be built out to achieve
> rich inter-convertibility. That has to be determined quickly by seeing
> how to build out the ability to even to take HTML5 edits into the same
> format begun with and find out where any practical difficulties become
> barriers.
>
+1 I too am not sure, and also not convinced it should be a high priority
target.
I sure hope the HTML5 is independent of whatever ODF version or document
type is uses as input. The idea of the HTML5 is that it provides a common
data model for all document types/versions, and the filters take care of
the conversions.
>
> 2. I think we are doing experimental design and we don't know when or
> whether
> significant redesign might be required and I don't think there is
> enough
> information right now to predict that. So the experiments must advance
> quickly.
>
+1, spending too much time designing the perfect solution, will most likely
not work. Once we have something, I believe refactoring is a small problem,
but not having anything at all is a big problem.
> 3. I think we presume too much about what it means to own your own
> documents.
> I'm for it, but it can't mean users have to learn how to maintain and
> port their own word-processing software, which is all that FOSS
> promises.
> Unfortunately, you get what you pay for, and maybe not even then.
>
I agree with this.
>
> Those are my concerns. I am certain you will find quite different
> concerns and expressions of faith from others here.
>
and they are very valid concerns. Let get started and then in 1-2 years
when we have done everything else, we can return and refine the filters.
We have so many things we want to do, so let us get the big lines done
first.
rgds
jan i.
>
> More below,
>
> - Dennis
>
> -- replying inline to --
> From: Gabriela Gibson [mailto:gabriela.gibson@gmail.com]
> Sent: Thursday, March 12, 2015 02:38
> To: dev@corinthia.incubator.apache.org; dennis.hamilton@acm.org
> Subject: Re: [CONF] Corinthia > ODF
>
> On Thu, Mar 12, 2015 at 2:37 AM, Dennis E. Hamilton <
> dennis.hamilton@acm.org
> > wrote:
>
> > Replying to both Gabriela and Jan comments farther below,
> >
> > 1. The TL;DR: Even though there are people still using StarOffice on a
> > Sun Workstation, I don't think these are a significant component of
> likely
> > Corinthia users. Our use of an intermediary is not likely to get us to
> > universal interconvertibility.
> >
> > (Peter: this also addresses your point :)
>
> I'm not saying we should actually do this (now).
>
> The question really is: Can we plan now for this to be possible, at a
> later time? And, can we get this possibility cheaply, en passant?
>
> That is, is there an elegant way in which to set up the architecture of
> this code, so that someone can easily add inter-convertibility later on?
>
> <orcmid>
> I think even inter-convertibility in the same format is a challenge with
> a model that is actually (1) a conversion from ODF to HTML5 (and
> whatever
> CSS and JS libraries that might be needed to make a fit) and (2) taking
> an *edited* HTML5 of that form and using it to figure out how to patch
> the ODF document in (1) to reflect the differences between the
> differences
> between the edited HTML5 and the original HTML produced from the ODF.
>
> It appears to be an article of faith that one can achieve high-fidelity
> interchange in this manner. I think that has to be tested by rapid
> development to determine where that may break down.
>
> I am reminded that the idea behind the HTML DOM was the possibility of
> exposing other formats through the same DOM. I have not explored that
> but it would seem to be a better way to get to (2). Perhaps any HTML5
> DOM is too limited, I don't know.
>
> I suspect the limitation on inter-convertibility via an HTML5
> intermediary
> is going to be arise in constraints on (1) the conversion of X to HTML5
> (with CSS, JS, and some sort of tagging) and (2) the conversion of HTML5
> (with all of that) to Y. I am certain there is an intersection where X
> to Y
> works but it is very difficult to know how far one can get in handling
> rich
> document formats and how easy that will be for any given legacy format,
> many
> of which are not well-documented and legacy processors may be hard to
> find
> and test with.
>
> I think the only way we will learn whatever the boundaries are and how
> difficult things may become as we go to preserve feature richness is to
> try it. And if a wall is hit, figure out how to remedy things and then
> go through the problem of dealing with Corinthia's own legacy.
> </orcmid>
>
> Also, say Corinthia gets to be (woo!) 20. We're (say) at ODF 6.0. Given
> the entire reason for ODF is the users' data freedom (that is you own your
> data and not some company and their fancy format), does it not behoove us
> not to allow versions of ODF own the users data?
>
> <orcmid>
> I am not sure I understand that. The problem with office-productivity
> formats is users do not own their documents, some software owns their
> documents and without appropriately capable software, those documents
> are not preserved. I am talking about the thousands of users who
> download ODF-based software every week and have no idea what the files
> look like and certainly have no way to deal with the software, however
> it is developed or supported. For them, the promise of FOSS is not
> meaningful because they are not equipped to read the code, let alone
> modify it or port it. For these users, if their needs are satisfied
> otherwise, the only difference between using, say Microsoft Office or
> WordPerfect is price and the problem of end-of-life of the software they
> need to have available.
> I agree about who should own the user's documents. But it is not
> exactly a format issue in the case of these document formats.
> </orcmid>
>
>
>
> Likewise, if possible, we should not limit tomorrows' committers either by
> our design decision today.
>
> <orcmid>
> I am not certain how one can be certain of this. I expect that we are
> limiting committers, but while the project is small it may be able to
> make changes and do the necessary rework. From things Peter says about
> what he wants in the future, it strikes me that rework will be
> inevitable.
>
> My sense is that Corinthia is at the code first to figure out a design
> stage of development. For me, it is very awkward to see how to scale
> out
> with very many committers at this point, when the design is an evolving
> experiment. I am certain that is not the way it is in the head of Peter
> and Jan, but that is how it is for me as an observer.
>
> The only way I know of is to experiment quickly and have some sort of
> continuous delivery that allows us to explore and catch limitations
> quickly. That's not easy to arrange and I have no brilliant ideas about
> how to do that here.
> </orcmid>
>
> If it's a PITA, then it of course should not be attempted, but ... if we
> can lunch for free, then please pass the ketchup! ;-)
>
> Also, what Dennis wrote below makes me think that much future pain can be
> avoided if we can pull such a design structure off.
>
> Question for Dennis: Where do you think ODF will be in 20 years time?
>
> <orcmid>
> I do not know where ODF will be in 20 years. At the moment, I
> would be surprised if there is ever an ODF 2.0 (and will it provide
> upward compatibility with older versions). The current effort is to
> get to ODF 1.3 and, except for a new treatment of change-tracking
> that is expected to replace/obsolete what is there now (and whatever
> those upward compatibility issues will be), I think it
> will be a maintenance release.
>
> A bigger question will be what the situation will be with regard to
> Software that is ODF-supporting. When the implementers are not able
> to absorb upgrades to ODF, I think that will determine the practical
> limit on ODF development.
>
> I have not been on the ODF Technical Committee since 2012, so I have
> no insider knowledge about this, although I do scan the mailing lists
> from time to time, and I still contribute suggestions and analysis
> on parts that interest me.
> </orcmid>
>
> G
>
>
> 2. It is necessary to support input of all versions that are known
> > especially because if a document says it is in ODF 1.2, that does not
> mean
> > it uses any features that are not in ODF 1.1, and if it is one of the
> > breaking cases, that can be handled if there is enough information about
> > the intended level of ODF. (But an ODF 1.2 implementation might still be
> > implementing an ODF 1.1 interpretation.).
> > For output, if it is not possible to indicate the actual level of
> > features employed, it is usually necessary to identify outputs as ODF
> 1.2.
> >
> > 3. IMPORTANT EXCEPTION: If the DocFilter implementations for ODF input
> and
> > ODF updating do not preserve any features used above a given ODF level,
> > that level should be indicated as the output level. (I.e., if ODF
> > 1.2-unique features are not even supported, don't call the output ODF
> 1.2,
> > no matter what the input is claimed to be.)
> >
> > This might well be a significant part of spiral development and
> > progressive integration of an ODF-support roadmap.
> >
> > - Dennis
> >
> > -----Original Message-----
> > From: Gabriela Gibson [mailto:gabriela.gibson@gmail.com]
> > Sent: Wednesday, March 11, 2015 16:43
> > To: dev@corinthia.incubator.apache.org
> > Cc: dennis.hamilton@acm.org
> > Subject: Re: [CONF] Corinthia > ODF
> >
> > On Wed, Mar 11, 2015 at 11:02 PM, jan i <ja...@apache.org> wrote:
> >
> > [ ... ]
> > > In my opinion, we must be able to read all versions, but only write
> the
> > > newest.
> > >
> > > This is a bit devil's advocate tale, but, it's a true story:
> >
> > [ ... ]
> >
> > So, there will be occasions where people will want to be able to use a
> > legacy program, because it makes life easier for them, or perhaps, an old
> > machine is all they can afford, or they simply don't want to enter
> upgrade
> > hell. When ODF 6.0 comes round (and it probably will, eventually) there
> > will be lots of people wanting/needing this kind of functionality.
> >
> > Also, Hackernews had an interesting discussion today:
> > https://news.ycombinator.com/item?id=9185356 --- maybe not quite
> > applicable to our situation here, but pretty similar.
> >
> > I think it's worthwhile to consider to make it bidirectional by basic
> > design.
> >
> > G
> >
> >
> >
>
>
> --
> Visit my Coding Diary: http://gabriela-gibson.blogspot.com/
>
>
RE: [CONF] Corinthia > ODF
Posted by "Dennis E. Hamilton" <de...@acm.org>.
The TL;DR on Gabriela's questions:
1. I am not confident that the Corinthia model can be built out to achieve
rich inter-convertibility. That has to be determined quickly by seeing
how to build out the ability to even to take HTML5 edits into the same
format begun with and find out where any practical difficulties become
barriers.
2. I think we are doing experimental design and we don't know when or whether
significant redesign might be required and I don't think there is enough
information right now to predict that. So the experiments must advance
quickly.
3. I think we presume too much about what it means to own your own documents.
I'm for it, but it can't mean users have to learn how to maintain and
port their own word-processing software, which is all that FOSS promises.
Unfortunately, you get what you pay for, and maybe not even then.
Those are my concerns. I am certain you will find quite different concerns and expressions of faith from others here.
More below,
- Dennis
-- replying inline to --
From: Gabriela Gibson [mailto:gabriela.gibson@gmail.com]
Sent: Thursday, March 12, 2015 02:38
To: dev@corinthia.incubator.apache.org; dennis.hamilton@acm.org
Subject: Re: [CONF] Corinthia > ODF
On Thu, Mar 12, 2015 at 2:37 AM, Dennis E. Hamilton <dennis.hamilton@acm.org
> wrote:
> Replying to both Gabriela and Jan comments farther below,
>
> 1. The TL;DR: Even though there are people still using StarOffice on a
> Sun Workstation, I don't think these are a significant component of likely
> Corinthia users. Our use of an intermediary is not likely to get us to
> universal interconvertibility.
>
> (Peter: this also addresses your point :)
I'm not saying we should actually do this (now).
The question really is: Can we plan now for this to be possible, at a
later time? And, can we get this possibility cheaply, en passant?
That is, is there an elegant way in which to set up the architecture of
this code, so that someone can easily add inter-convertibility later on?
<orcmid>
I think even inter-convertibility in the same format is a challenge with
a model that is actually (1) a conversion from ODF to HTML5 (and whatever
CSS and JS libraries that might be needed to make a fit) and (2) taking
an *edited* HTML5 of that form and using it to figure out how to patch
the ODF document in (1) to reflect the differences between the differences
between the edited HTML5 and the original HTML produced from the ODF.
It appears to be an article of faith that one can achieve high-fidelity
interchange in this manner. I think that has to be tested by rapid
development to determine where that may break down.
I am reminded that the idea behind the HTML DOM was the possibility of
exposing other formats through the same DOM. I have not explored that
but it would seem to be a better way to get to (2). Perhaps any HTML5
DOM is too limited, I don't know.
I suspect the limitation on inter-convertibility via an HTML5 intermediary
is going to be arise in constraints on (1) the conversion of X to HTML5
(with CSS, JS, and some sort of tagging) and (2) the conversion of HTML5
(with all of that) to Y. I am certain there is an intersection where X to Y
works but it is very difficult to know how far one can get in handling rich
document formats and how easy that will be for any given legacy format, many
of which are not well-documented and legacy processors may be hard to find
and test with.
I think the only way we will learn whatever the boundaries are and how
difficult things may become as we go to preserve feature richness is to
try it. And if a wall is hit, figure out how to remedy things and then
go through the problem of dealing with Corinthia's own legacy.
</orcmid>
Also, say Corinthia gets to be (woo!) 20. We're (say) at ODF 6.0. Given
the entire reason for ODF is the users' data freedom (that is you own your
data and not some company and their fancy format), does it not behoove us
not to allow versions of ODF own the users data?
<orcmid>
I am not sure I understand that. The problem with office-productivity
formats is users do not own their documents, some software owns their
documents and without appropriately capable software, those documents
are not preserved. I am talking about the thousands of users who
download ODF-based software every week and have no idea what the files
look like and certainly have no way to deal with the software, however
it is developed or supported. For them, the promise of FOSS is not
meaningful because they are not equipped to read the code, let alone
modify it or port it. For these users, if their needs are satisfied
otherwise, the only difference between using, say Microsoft Office or
WordPerfect is price and the problem of end-of-life of the software they
need to have available.
I agree about who should own the user's documents. But it is not
exactly a format issue in the case of these document formats.
</orcmid>
Likewise, if possible, we should not limit tomorrows' committers either by
our design decision today.
<orcmid>
I am not certain how one can be certain of this. I expect that we are
limiting committers, but while the project is small it may be able to
make changes and do the necessary rework. From things Peter says about
what he wants in the future, it strikes me that rework will be inevitable.
My sense is that Corinthia is at the code first to figure out a design
stage of development. For me, it is very awkward to see how to scale out
with very many committers at this point, when the design is an evolving
experiment. I am certain that is not the way it is in the head of Peter
and Jan, but that is how it is for me as an observer.
The only way I know of is to experiment quickly and have some sort of
continuous delivery that allows us to explore and catch limitations
quickly. That's not easy to arrange and I have no brilliant ideas about
how to do that here.
</orcmid>
If it's a PITA, then it of course should not be attempted, but ... if we
can lunch for free, then please pass the ketchup! ;-)
Also, what Dennis wrote below makes me think that much future pain can be
avoided if we can pull such a design structure off.
Question for Dennis: Where do you think ODF will be in 20 years time?
<orcmid>
I do not know where ODF will be in 20 years. At the moment, I
would be surprised if there is ever an ODF 2.0 (and will it provide
upward compatibility with older versions). The current effort is to
get to ODF 1.3 and, except for a new treatment of change-tracking
that is expected to replace/obsolete what is there now (and whatever
those upward compatibility issues will be), I think it
will be a maintenance release.
A bigger question will be what the situation will be with regard to
Software that is ODF-supporting. When the implementers are not able
to absorb upgrades to ODF, I think that will determine the practical
limit on ODF development.
I have not been on the ODF Technical Committee since 2012, so I have
no insider knowledge about this, although I do scan the mailing lists
from time to time, and I still contribute suggestions and analysis
on parts that interest me.
</orcmid>
G
2. It is necessary to support input of all versions that are known
> especially because if a document says it is in ODF 1.2, that does not mean
> it uses any features that are not in ODF 1.1, and if it is one of the
> breaking cases, that can be handled if there is enough information about
> the intended level of ODF. (But an ODF 1.2 implementation might still be
> implementing an ODF 1.1 interpretation.).
> For output, if it is not possible to indicate the actual level of
> features employed, it is usually necessary to identify outputs as ODF 1.2.
>
> 3. IMPORTANT EXCEPTION: If the DocFilter implementations for ODF input and
> ODF updating do not preserve any features used above a given ODF level,
> that level should be indicated as the output level. (I.e., if ODF
> 1.2-unique features are not even supported, don't call the output ODF 1.2,
> no matter what the input is claimed to be.)
>
> This might well be a significant part of spiral development and
> progressive integration of an ODF-support roadmap.
>
> - Dennis
>
> -----Original Message-----
> From: Gabriela Gibson [mailto:gabriela.gibson@gmail.com]
> Sent: Wednesday, March 11, 2015 16:43
> To: dev@corinthia.incubator.apache.org
> Cc: dennis.hamilton@acm.org
> Subject: Re: [CONF] Corinthia > ODF
>
> On Wed, Mar 11, 2015 at 11:02 PM, jan i <ja...@apache.org> wrote:
>
> [ ... ]
> > In my opinion, we must be able to read all versions, but only write the
> > newest.
> >
> > This is a bit devil's advocate tale, but, it's a true story:
>
> [ ... ]
>
> So, there will be occasions where people will want to be able to use a
> legacy program, because it makes life easier for them, or perhaps, an old
> machine is all they can afford, or they simply don't want to enter upgrade
> hell. When ODF 6.0 comes round (and it probably will, eventually) there
> will be lots of people wanting/needing this kind of functionality.
>
> Also, Hackernews had an interesting discussion today:
> https://news.ycombinator.com/item?id=9185356 --- maybe not quite
> applicable to our situation here, but pretty similar.
>
> I think it's worthwhile to consider to make it bidirectional by basic
> design.
>
> G
>
>
>
--
Visit my Coding Diary: http://gabriela-gibson.blogspot.com/
Re: [CONF] Corinthia > ODF
Posted by Gabriela Gibson <ga...@gmail.com>.
On Thu, Mar 12, 2015 at 2:37 AM, Dennis E. Hamilton <dennis.hamilton@acm.org
> wrote:
> Replying to both Gabriela and Jan comments farther below,
>
> 1. The TL;DR: Even though there are people still using StarOffice on a
> Sun Workstation, I don't think these are a significant component of likely
> Corinthia users. Our use of an intermediary is not likely to get us to
> universal interconvertibility.
>
> (Peter: this also addresses your point :)
I'm not saying we should actually do this (now).
The question really is: Can we plan now for this to be possible, at a
later time? And, can we get this possibility cheaply, en passant?
That is, is there an elegant way in which to set up the architecture of
this code, so that someone can easily add inter-convertibility later on?
Also, say Corinthia gets to be (woo!) 20. We're (say) at ODF 6.0. Given
the entire reason for ODF is the users' data freedom (that is you own your
data and not some company and their fancy format), does it not behoove us
not to allow versions of ODF own the users data?
Likewise, if possible, we should not limit tomorrows' committers either by
our design decision today.
If it's a PITA, then it of course should not be attempted, but ... if we
can lunch for free, then please pass the ketchup! ;-)
Also, what Dennis wrote below makes me think that much future pain can be
avoided if we can pull such a design structure off.
Question for Dennis: Where do you think ODF will be in 20 years time?
G
2. It is necessary to support input of all versions that are known
> especially because if a document says it is in ODF 1.2, that does not mean
> it uses any features that are not in ODF 1.1, and if it is one of the
> breaking cases, that can be handled if there is enough information about
> the intended level of ODF. (But an ODF 1.2 implementation might still be
> implementing an ODF 1.1 interpretation.).
> For output, if it is not possible to indicate the actual level of
> features employed, it is usually necessary to identify outputs as ODF 1.2.
>
> 3. IMPORTANT EXCEPTION: If the DocFilter implementations for ODF input and
> ODF updating do not preserve any features used above a given ODF level,
> that level should be indicated as the output level. (I.e., if ODF
> 1.2-unique features are not even supported, don't call the output ODF 1.2,
> no matter what the input is claimed to be.)
>
> This might well be a significant part of spiral development and
> progressive integration of an ODF-support roadmap.
>
> - Dennis
>
> -----Original Message-----
> From: Gabriela Gibson [mailto:gabriela.gibson@gmail.com]
> Sent: Wednesday, March 11, 2015 16:43
> To: dev@corinthia.incubator.apache.org
> Cc: dennis.hamilton@acm.org
> Subject: Re: [CONF] Corinthia > ODF
>
> On Wed, Mar 11, 2015 at 11:02 PM, jan i <ja...@apache.org> wrote:
>
> [ ... ]
> > In my opinion, we must be able to read all versions, but only write the
> > newest.
> >
> > This is a bit devil's advocate tale, but, it's a true story:
>
> [ ... ]
>
> So, there will be occasions where people will want to be able to use a
> legacy program, because it makes life easier for them, or perhaps, an old
> machine is all they can afford, or they simply don't want to enter upgrade
> hell. When ODF 6.0 comes round (and it probably will, eventually) there
> will be lots of people wanting/needing this kind of functionality.
>
> Also, Hackernews had an interesting discussion today:
> https://news.ycombinator.com/item?id=9185356 --- maybe not quite
> applicable to our situation here, but pretty similar.
>
> I think it's worthwhile to consider to make it bidirectional by basic
> design.
>
> G
>
>
>
--
Visit my Coding Diary: http://gabriela-gibson.blogspot.com/
RE: [CONF] Corinthia > ODF
Posted by "Dennis E. Hamilton" <de...@acm.org>.
Replying to both Gabriela and Jan comments farther below,
1. The TL;DR: Even though there are people still using StarOffice on a Sun Workstation, I don't think these are a significant component of likely Corinthia users. Our use of an intermediary is not likely to get us to universal interconvertibility.
2. It is necessary to support input of all versions that are known especially because if a document says it is in ODF 1.2, that does not mean it uses any features that are not in ODF 1.1, and if it is one of the breaking cases, that can be handled if there is enough information about the intended level of ODF. (But an ODF 1.2 implementation might still be implementing an ODF 1.1 interpretation.).
For output, if it is not possible to indicate the actual level of features employed, it is usually necessary to identify outputs as ODF 1.2.
3. IMPORTANT EXCEPTION: If the DocFilter implementations for ODF input and ODF updating do not preserve any features used above a given ODF level, that level should be indicated as the output level. (I.e., if ODF 1.2-unique features are not even supported, don't call the output ODF 1.2, no matter what the input is claimed to be.)
This might well be a significant part of spiral development and progressive integration of an ODF-support roadmap.
- Dennis
-----Original Message-----
From: Gabriela Gibson [mailto:gabriela.gibson@gmail.com]
Sent: Wednesday, March 11, 2015 16:43
To: dev@corinthia.incubator.apache.org
Cc: dennis.hamilton@acm.org
Subject: Re: [CONF] Corinthia > ODF
On Wed, Mar 11, 2015 at 11:02 PM, jan i <ja...@apache.org> wrote:
[ ... ]
> In my opinion, we must be able to read all versions, but only write the
> newest.
>
> This is a bit devil's advocate tale, but, it's a true story:
[ ... ]
So, there will be occasions where people will want to be able to use a
legacy program, because it makes life easier for them, or perhaps, an old
machine is all they can afford, or they simply don't want to enter upgrade
hell. When ODF 6.0 comes round (and it probably will, eventually) there
will be lots of people wanting/needing this kind of functionality.
Also, Hackernews had an interesting discussion today:
https://news.ycombinator.com/item?id=9185356 --- maybe not quite
applicable to our situation here, but pretty similar.
I think it's worthwhile to consider to make it bidirectional by basic
design.
G
Re: [CONF] Corinthia > ODF
Posted by Gabriela Gibson <ga...@gmail.com>.
On Wed, Mar 11, 2015 at 11:02 PM, jan i <ja...@apache.org> wrote:
> On Wednesday, March 11, 2015, Gabriela Gibson <ga...@gmail.com>
> wrote:
>
> > Does this mean that we should consider catering for ODF_some_func_1.[x|y]
> > in some cases where 1.x and 1.y are different, and that we need some kind
> > of sandwich layer that automagically selects the correct version to use
> for
> > the standard we are processing?
> >
> > Say, I want that LaTeX doc in ODF 1.1 instead of 1.2. Or perhaps I want
> to
> > go from ODF 1.0 to ODF 1.2 (or vice versa).
>
>
> In my opinion, we must be able to read all versions, but only write the
> newest.
>
> This is a bit devil's advocate tale, but, it's a true story:
I know of at least one secretary who in 2000 was the only person in the
entire university to still use Wordstar, because 'this is what she was used
to', and systems (and everyone else) humoured her.
So, there will be occasions where people will want to be able to use a
legacy program, because it makes life easier for them, or perhaps, an old
machine is all they can afford, or they simply don't want to enter upgrade
hell. When ODF 6.0 comes round (and it probably will, eventually) there
will be lots of people wanting/needing this kind of functionality.
Also, Hackernews had an interesting discussion today:
https://news.ycombinator.com/item?id=9185356 --- maybe not quite
applicable to our situation here, but pretty similar.
I think it's worthwhile to consider to make it bidirectional by basic
design.
G
rgds
> jan i
>
> >
> > G
> >
>
>
> --
> Sent from My iPad, sorry for any misspellings.
>
--
Visit my Coding Diary: http://gabriela-gibson.blogspot.com/
Re: [CONF] Corinthia > ODF
Posted by jan i <ja...@apache.org>.
On Wednesday, March 11, 2015, Gabriela Gibson <ga...@gmail.com>
wrote:
> Does this mean that we should consider catering for ODF_some_func_1.[x|y]
> in some cases where 1.x and 1.y are different, and that we need some kind
> of sandwich layer that automagically selects the correct version to use for
> the standard we are processing?
>
> Say, I want that LaTeX doc in ODF 1.1 instead of 1.2. Or perhaps I want to
> go from ODF 1.0 to ODF 1.2 (or vice versa).
In my opinion, we must be able to read all versions, but only write the
newest.
rgds
jan i
>
> G
>
--
Sent from My iPad, sorry for any misspellings.
Re: [CONF] Corinthia > ODF
Posted by Gabriela Gibson <ga...@gmail.com>.
Does this mean that we should consider catering for ODF_some_func_1.[x|y]
in some cases where 1.x and 1.y are different, and that we need some kind
of sandwich layer that automagically selects the correct version to use for
the standard we are processing?
Say, I want that LaTeX doc in ODF 1.1 instead of 1.2. Or perhaps I want to
go from ODF 1.0 to ODF 1.2 (or vice versa).
G
RE: [CONF] Corinthia > ODF
Posted by "Dennis E. Hamilton" <de...@acm.org>.
-- replying below to --
From: jan i [mailto:jani@apache.org]
Sent: Wednesday, March 11, 2015 10:13
To: dev@corinthia.incubator.apache.org; orcmid@apache.org
Subject: Re: [CONF] Corinthia > ODF
[ ... ]
Good work, both of you. A little question should we try to get hold of the
newer standard, or does it not really matter ?
<orcmid>
ODF 1.0 was barely used before ODF 1.1 was introduced. ODF 1.1 was essentially a maintenance release, with the addition of some provisions to support accessibility. The current international standard and ODF 1.1 are at a common level, so one should always use ODF 1.1 and not ODF 1.0. ODF 1.0 documents are a subset anyhow.
Since OpenOffice 3.x, the main support has been to some degree of ODF 1.2. To handle spreadsheets, ODF 1.2 is definitely the one to employ.
There are a couple of breaking changes between 1.1 and 1.2 and otherwise, 1.1 works as a subset of 1.2 unless the 1.1 does not fit within the more-specific conformance requirements for 1.2.
In addition to supporting ODF as such, there is the small matter of implementation-defined and implementation-dependent cases, including where an implementation does not interpret a feature or where it has a non-standard exception.
I think that is where we enter the scope of Corinthia with regard to profiling its support for formats and also developing profiles of how other producers make conformant documents comes into play.
Conformance information is available for the compliance with ODF in Microsoft Office, although it appears to be incomplete. For the OpenOffice.org family, I don't think the information has ever been made available in end-user or general-public understandable form with some sort of keying to the relevant standard(s).
</orcmid>
rgds
jan I.
[ ... ]
Re: [CONF] Corinthia > ODF
Posted by jan i <ja...@apache.org>.
On 11 March 2015 at 16:43, Dennis E. Hamilton <or...@apache.org> wrote:
> Nice catch! That is a 2005 book and it has some deviations to watch out
> for. It is based on ODF 1.0 and also rather wedded to OpenOffice 1.9 (in
> contrast with the 3.x and now 4.x series).
>
>
>
> I split up General Information to add a section on processing resources
> after the information about the standards, and include OASIS OpenDocument
> Essentials in it. [That assumes that Confluence does not continue to be
> spinning on my attempt to commit the changes.]
>
>
>
> Sorry for top posting in this manner. But these HTML-formatted posts are
> difficult to do anything else with. So long as I am given HTML
> formatting, I will be top posting.
>
Please forgive me for making a little joke....I remember a person who wrote
a strong mail about him never going to use cwiki :-)
Sorry about that, no offense intended, I am happy to see how our team work
really starts to take off.
Good work, both of you. A little question should we try to get hold of the
newer standard, or does it not really matter ?
rgds
jan I.
Ps. As I just wrote in another mail, too much HTML in a mail, and it lands
on the moderator table, which is no fun. So maybe we should start to use
plain text like Dennis indirectly suggest, I am in favor of using plain
text.
>
>
> - Dennis
>
>
>
> *From:* Gabriela Gibson (Confluence) [mailto:confluence@apache.org]
> *Sent:* Wednesday, March 11, 2015 05:57
> *To:* orcmid@apache.org
> *Subject:* [CONF] Corinthia > ODF
>
>
>
> Gabriela Gibson edited the page:
> *ODF <https://cwiki.apache.org/confluence/display/Corinthia/ODF>*
>
> *Comment:* Added links to OASIS OpenDocument Essentials book.
> *General Information*
>
> An introductory book can be obtained here: OASIS OpenDocument Essentials
> HTML <http://books.evc-cit.info/odbook/book.html> PDF
> <http://books.evc-cit.info/OD_Essentials.pdf>
>
> ...
>
> View Online <https://cwiki.apache.org/confluence/display/Corinthia/ODF> · View
> Changes
> <https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=53739751&revisedVersion=5&originalVersion=4>
> · Add Comment
> <https://cwiki.apache.org/confluence/display/Corinthia/ODF?showComments=true&showCommentArea=true#addcomment>
>
> Stop watching page
> <https://cwiki.apache.org/confluence/users/removepagenotification.action?pageId=53739751>
> · Manage Notifications
> <https://cwiki.apache.org/confluence/users/editmyemailsettings.action>
>
> This message was sent by Atlassian Confluence
> <http://www.atlassian.com/software/confluence> 5.0.3, Team Collaboration
> Software
> <http://www.atlassian.com/software/confluence/overview/team-collaboration-software?utm_source=email-footer>
>
>
>