[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] The Rule of Least Power
Thomas Zander <T.Zander@nokia.com> wrote on 02/12/2009 09:24:36 AM: > > On Thursday 12. February 2009 13:53:02 ext robert_weir@us.ibm.com wrote: > > > That mail just posts some anonymous element; thats not a usecase. > > > I can't even argue that the "foo:bar" is or is not a loss if an > > > implementation > > > ignores it since you don't give a realistic usecase to argue from. > > > > But that's the important point. From the perspective of an general ODF > > consumer, say a word processor, these private extensions are opaque, > > without any discernible semantics, just like foo:bar. > > yes, thats the point of adding data that is not in the ODF spec. Its private > data required by the implementation to not loose information. > > Can you give me any usecase where any type of extention would be > useful to any > implementation that is not the one that wrote it? > Or, in other words; what advantage does it give us to move this private data > to pre-defined extention positions? > Certainly if we define extensions in a way that consuming applications can do nothing but throw out the extension data, then the use of extensions will be limited to rendering hints and other low-value, throw-away uses. But what we lose in this case is the ability to have extension data that can be round-tripped, i.e., is preserved in a document even when the document is edited and re-saved. If the extension data has any value to the author at all, I expect that he would express at least some dissatisfaction if such extension data is automatically lost if the document is edited in another application. > Do note that we already *have* pre-defined extension positions, specifically > metadata. So this is not about adding some metadata that I'd like to survive > a simple load/save by a random ODF implementation. Thats a solved problem. > > > > I'd rather call a real usecase where things go really wrong 'proof' ;) > > > > The entire point of my criticism is that the consumer of an extended > > document just sees arbitrary XML. It has no knowledge of use cases, of > > what that extension is for. It just sees foo:bar. It is a black box. > > Yes, and there is nothing you can do to open that black box. If > KOffice or Qts > ODFWriter decides it needs to store some data to make saving loading to its > native format not loose info, and that information doesn't fit in any ODF > tag, then you get a black box. In some sense even a "black box" has a degree of interoperability, since I know how to copy and move a box. It is as interoperable as any box. But what we have with general foreign markup extensions is more like a "black haze". The consumer doesn't know how to interpret, which is fine, but they won't know hot to copy it, move it, etc. > Thats a fact of life. Arguing thats a bad idea is equivalent to > saying we need > to document each and every possible piece of data in the ODF specification. > And I think we don't want that. Do we? > I think of it this way. We're not putting binary blob extensions into the document, arbitrary bits in arbitrary places. We use XML, and XML defines the basic level of syntax and structure for the extensions. If we require a schema definition for the extension data, then additional constraints related to data type, ranges, cardinality, etc. are defined. But in an editing envrionment, we have additional concerns that are not covered by RNG or XML Schema, things like whether the data is volatile or not, whether it can be copied, whether data can be changed without invalidating the extension data, etc. A possible solution: 1) If we allow general, arbitrary extensions, then we need a vocabulary for allowing the extensions to declare how the data should be processed, specifically whether it should be preserved under copies, edits, etc. Maybe the default is that it is never preserved until declared otherwise. 2)If we find that there are a small number of patterns of extension, then we could make a conformance statement specifically for them. For example, I bet a large number of extensions will fit into the pattern of simple namespaced attribute/value pairs which decorate content elements and travel with the underlying content when copied or moved, and which may safely be preserved when the underlying content is edited. In the end, I want to avoid extension soup. I acknowledge that there are good and useful extensions, but in practice they will not be all that useful, to users, if all applications just throw the extension data out. I'd like to see if we can standardize some basic "rules of the road" so they can be preserved when edited. -Rob
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]