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

Hi Jesper,

2009/2/25 Jesper Lund Stocholm <4a4553504552@gmail.com>:
> Hi Rob,
> 2009/2/8  <robert_weir@us.ibm.com>:
>> That's why I favor removing it from the ODF core.  Having it there just
>> makes work for implementations to write code to handle it "just in case",
>> even though no one currently uses the feature.
> The more I think of the idea of multiple conformance clauses the more
> I actually like it. However, a few details are not clear to me yet, so
> please endulge me to broaden my view:
> What would be the purpose of having multiple conformance clauses -
> apart from complying with OASIS rules? Is it for procurement concerns?
> Is it to enable organisations to aquire either "ODF Core compliant
> applications" or "ODF Extended compliant applications"?
> Also, will an application be able to recognize a core document vs an
> extended document (apart from detecting foreign content)? Will there
> be a flag to indicate compliance level?
> As a principle, I like the idea of stripping out what is not needed or
> "pure" (after all, that was kind of the idea of making
> strict/transitional editions of OOXML during processing in ISO). But I
> think it is important to think about what vendors will do if the two
> clauses are kept. Chances are that they will flash "ODF Core
> compliant" even though they are only this in theory since their
> default behaviour is the extended edition. This is actually much the
> same way OOo claims "Compatible with Microsoft Office" when in theory
> it is compatible, but it is not when using the default file format.
> This is about the same mess we have with OOXML and strict/transitional
> and Microsoft Office. Office 14 will likely support both strict and
> transitional OOXML, but since backwards compliance is important to
> Microsoft, default behaviour will propably be "transitional".
> And finally: a lot of the discussions on the web about this has
> circled about documents not being conformant when being extended (and
> I realize that I might have contributed to this). As far as I
> understand it this is not true. Documents with extensions will indeed
> be conformant - but to the "OpenDocument extended document" and not to
> the core "OpenDocument conformance".
> And a personal fear: Focusing on shrinking ODF to "ODF Core" risks
> making it increasingly difficult to claim that ODF is a "full fledged
> alternative to .DOC and OOXML". I think that would be a wrong path the
> go. ODF /must/ remain a viable alternative to .DOC and OOXML.

I agree with your assessment of the possible consequences of some of
these decisions.  Personally I don't like to think of ODF core as
being a "stripped" version - though I have seen calls from some
quarters for such a beast.  ODF core should certainly be as
feature-complete as possible.  ODF Extended, by its nature, will spawn
a variety of application specific variants.  Some of which may be
benign from an interop perspective, and others which can create an
interoperability nightmare between applications.  But they might have
genuine usefulness in internal environments.  And I suppose it is
quite possible that extensions born of this mechanism could ultimately
become de facto standard by there usefulness and find there way back
into the core.

I do remember the process which brought about the conformance classes
of OOXML - which addressed how to deal with a growing appendix of
deprecated features.  I think extended in this context is designed
more to address extensibility than deprecation.  Of course there is
some overlap.


> Jesper Lund Stocholm
> www.idippedut.dk
> SC34/WG4 http://www.itscj.ipsj.or.jp/sc34/wg4/
> --
> This publicly archived list offers a means to provide input to the
> OASIS Open Document Format for Office Applications (OpenDocument) TC.
> In order to verify user consent to the Feedback License terms and
> to minimize spam in the list archive, subscription is required
> before posting.
> Subscribe: office-comment-subscribe@lists.oasis-open.org
> Unsubscribe: office-comment-unsubscribe@lists.oasis-open.org
> List help: office-comment-help@lists.oasis-open.org
> List archive: http://lists.oasis-open.org/archives/office-comment/
> Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
> Committee: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office

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