[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] ODF 1.2 Single-Level Conformance and Law of UnintendedConsequences
I agree with you on almost all of your points, but I'd frame it differently. First, the use of XML provides extensibility. This is an undeniable benefit of the technology. However, this is not the same as saying the ODF standard should define conformance to allow extensions beyond the schema defined by the standard. These are two different things. One does not imply the other. You properly use the example of HTML as an format where useful extensions have been made. But when you look at the XHTML Recommendation, you'll find that it only defines strict conformance, and in fact states that mixing XHTML with other namespaces is not conformant (section 3.1.2). Certainly the fact that XHTML does not allow extensions in conformant documents has not prevented innovation? We can't prevent extensions, and we shouldn't try, IMHO, Extensions, at least where the user has some control over where and when they are used, are powerful tools. But the user does not have control if they think they are using ODF but their word processor is putting undocumented, incompatible and non-interoperable extensions into their documents. That said, I'd be less adverse to having both strict and loose conformance classes if we also required that ODF Producers have a mode of operation where they would create only strictly conformant documents. Then that puts the control back into the user's hands as to what mode they want to operate in. -Rob David Faure <faure@kde.org> wrote on 01/20/2009 01:02:34 PM: > > On Monday 19 January 2009, robert_weir@us.ibm.com wrote: > > David Faure <faure@kde.org> wrote on 01/19/2009 02:10:28 PM: > > > > > > > > On Monday 19 January 2009, robert_weir@us.ibm.com wrote: > > > > Since current implementations do not (to my > > > > knowledge) introduce foreign attributes and elements into > documents, they > > > > would not be impacted by this change. > > > > > > By foreign, do you mean attributes and elements not defined by ODF? > > > Then I beg to differ, there are plenty of these, see below. > > > > We talking about ODF 1.0 and ODF 1.1, section 1.5 Document Conformance, " > > Documents that conform to the OpenDocument specification may contain > > elements and attributes not specified within the OpenDocument schema." > > We're considering restricting this. > > I would like to know why exactly. The whole point of using XML and > not a binary > format is to make such extensions possible, and just like I can > write additional > attributes (or even comments) in HTML that webbrowsers will ignore (but that > a specific tool could interpret), koffice should be able to write > koffice-specific > attributes in an ODF document, as long as these do not affect > interoperability. > > > > * KWord can define the behavior of a frame when a new page is > > > created (for DTP-like usage > > > where you might want a similar frame to be created on the next page > > > at the exact same position; > > > another one use case is a company logo in a page corner for instance). > > > This is done with koffice:frame-behavior-on-new-page in the frame > > > style; and here again it > > > only affects further editing, not rendering of a given document. > > > > Yes, I believe so. Would it be too much trouble to eliminate these in > > KOffice as part of supporting ODF 1.2? For example, can they be expressed > > using another ODF mechanism? > > Not that I know. And since it's too late for new proposals for 1.2, the idea > that "any extension should be standardized" doesn't hold. It doesn't > hold in general, > anyway -- this idea kills innovation and forces everyone to > implement the exact > same thing. You have to understand that if an office suite decides to use > ODF as its **NATIVE** document format, not some export functionalitywhere some > data could be lost, then ODF _has_ to provide a way for that office suite to > save anything it wants to save into the document, even things that > might not be > standardized... : > - ... due to lack of interest from other implementors > - ... yet (to be standardized in a future version but not standardized yet) > - ... because the attribute is used for very internal reasons, sometimes even > to _increase_ interoperability (e.g. in KOffice we have to create a > wrapper frame > to map a koffice feature with valid ODF, but we better recognize it > as such so that > we don't actually show it in KOffice). All such cases where the view > of things in > one app differs slightly from the view of things in another app, are reasons > for such extensions, which are not necessarily harmful to interoperability, > on the contrary. > > > Although in your particular case, these may be benign and not effect > > rendering, you can see how in general this mechanism can easily be abused. > > So for fear of abuse you want to forbid any kind of extension? This doesn't > make sense to me. Remember "innocent until proven guilty"? :-) > > > It is hard enough for an implementation to ensure interoperability with > > what ODF does actually define, without having to also worry about what > > another implementation might add to an ODF document which is undefined. > > But that's the point: other implementations are NOT supposed to care for > those extensions. If they feel the need to do that, then indeed > those extensions > should be standardized instead. > > Don't get me wrong, I'm all for standardizing as much as possible, but this TC > has to realize that this isn't always possible. Are you saying that > we would accept > ANY feature request? Obviously not. So if we don't accept something in ODF, > and we don't find a compromise that would make everyone happy, what's going to > happen? Either the implementors requesting it will drop the idea > altogether (right...) > or they will just go ahead and use an extension for it. But since nobody else > in the TC wanted that feature, why would we care? Something that only > exists in one application cannot by definition be interoperable in > the first place, > that's not a document format issue, that's an application feature > set difference issue. > > If it's still valid for KOffice-2.0 I will try to get you all to > accept an equivalent > of koffice:frame-behavior-on-new-page in the next version of ODF, > but meanwhile > the use of extensions will have to stay, obviously. And things like > referring to > a style from another style, well, I'm having some trouble to get the similar > "user-defined character and paragraph styles" accepted... > > -- > David Faure, faure@kde.org, sponsored by Qt Software @ Nokia to work on KDE, > Konqueror (http://www.konqueror.org), and KOffice ( http://www.koffice.org). > > --------------------------------------------------------------------- > 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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]