OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [office-comment] Foreign elements and attributes


Your anecdotes do not support your argument.  If I'm reading it correctly, 
you are saying that we should allow extensions because extensions are 
useful to integrators.  But then you list three examples of how you were 
not able to accomplish what you wanted in ODF 1.1, even though ODF 1.1 
allows these extensions.

As I've written elsewhere, I think we need an extension framework to make 
extensions work.  Otherwise there is insufficient information declared in 
the instances to allow producers and consumers to negotiate issues such as 
versioning, fall-backs, preservation under editing, uniqueness, reference 
and volatility semantics, etc. MCE covers some of this, but not enough. 

-Rob


rjelliffe@allette.com.au wrote on 03/01/2009 09:54:49 AM:
.
.
.
> 
> I have had three use cases where this issue was a showstopper for ODF, 
due
> to the incorrect implementation of this feature.
> 
> The first was for for a particular branch of our Department of Defense,
> asking whether they could integrate ODF or OOXML applications for their
> XML/SGML based system, which has been in use since the mid 90s. Even
> though there were some good features in ODF 1.1 and OOXML (XForms, etc),
> they *both* variously lacked enough metadata or structuring capabilities
> for me to recommend in that processing chain, which is a shame.
> 
> The second use case was to represent XBRL documents in a standard 
document
> format. OOXML SpreadsheetML could not do it. ODF 1.1 could not do it.
> However OOXML WordProcessingML could in fact do it.
> 
> The third was for a web-based collaboration environment, where we hoped
> that if it adopted ODF as its internal format, this would help it with
> handling documents with rich markup. The requirement was for
> round-tripping, and integration into other non-web based tools.
> Unfortunately, due to ODF implementations' poor support for the ODF
> standard in this regard, it was not really feasible.
> 
> I found and reported a bug with OpenOffice in this regard, and have IIRC
> notified the ODF TC that the old text was incomplete in this regard (I
> think Florian Reuter of Novell made a follow up comment to me.) I 
suppose
> it is nice if you have a bug that you can find some flimsy excuse to get
> it made part of the standard, rather than having to fix your code and
> delivering the functionality that was decided as necessary by the 
initial
> ODF TC!
> 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]