[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] The Rule of Least Power
Thomas 2009/2/16 Thomas Zander <T.Zander@nokia.com>: > On Friday 13. February 2009 22:58:46 ext Jomar Silva wrote: >> Every time I see discussions like this one I remember the good and old >> KISS methodology. >> >> It is clear to me that we have, at least, two different user cases here, >> and we are trying to discuss them as if they are the same one. >> >> They are: >> >> 1. Users that need to have the ability to exchange their office suite >> (or application) as they change they socks. They also need to get >> assured that anyone who need to exchange documents with them will be >> able to use any office suite too, without missing anything (features or >> data or even formating properties). For those users (typically >> governments), a "strict conformance" class is absolutely necessary (and >> I have several real world histories and use cases in Brazil to >> illustrate this scenario...). >> >> 2. Users that may have the opportunity to define (or develop) a specific >> office suite (or office application) tho their use, that will accept and >> treat some additional data inside their ODF documents, that are useful >> on their corporate environment (and may or not, be useful to others). >> Those users can easily define that Jomar's Office is the best >> application to their own needs and define that they'll only use that >> application (despite if it generate "strict" or "extended" ODF documents). > > I think this looks good at first, but thinking a bit more about it, I get the > strong impression its a bit too simplistic. Too much black/white. > Lets use the usecase of koffice:nodeTypes again, which is an attribute saved > in a path. > The property is saved to allow the user to edit the path and the path will > remember the type of node. If you ever edited a vector path you know that it > is build up from 'nodes' that have one or more control points. The way you > interact with this depends on the node-type. > > The suggestion to make koffice save 'strict conforming' data then basically > means that you will always loose the information of which type of control you > are editing. Making re-editing rather annoying, but not much more. > > Therefor I think having this information saved even in an 'strict conformance' > mode does not harm anyone and only helps the user not loose part of his work, > which is really critical for using ODF as a native format for professional > vector editors. It sound like you are saying that ODF is missing a critical feature for professional vector editing (I don't pretend to be an expert on vector editing but I understand the idea). Have you proposed such a feature for 1.2? I don't recall seeing it. If not, it sounds like this is a really good candidate for requirements collection for the next version. > In conclusion this one example falls between the two usecases. No government > will care at all that this extension is there and forcing KOffice to not save > it will just harm the user that uses the same app for re-editing. Wrong. What we want to avoid is any kind of return to application specific formats. What we want are standard document formats. There are strong democratic and pragmatic imperatives which drive this logic. Now I like Koffice, but I also really want it to produce standard documents. The problem is that all the many vendors involved can and will say that their application can do a little something a little better than what the standard specifies. That is understandable. Vendors want to differentiate their products after all. But the way I see it, you have two choices: (1) if the feature is sufficiently critical - propose it for inclusion (2) if it is a "nice to have" peculiar to the functionality of a particular application, then you can produce an odf-hosted (I still prefer hosted to extended - I'll just use the term one last time) xml stream which contains your extended node descriptions. > In fact, I want to go back to the origin of the reason for asking for usecase > (1) in the first place. > I'm curious if others can come up with an example where an implementation > extending ODF using namespaces is willingly hurting ODF and thus something we > need to enhance the spec to protect against, as this proposal does. Willing or unwilling is not the point. Even hurting ODF is not the point. If it hurts the users who have an expectation that an odf document is an odf document, then that is something which I fear. I guess there's always a bit of a tradeoff - what is good for one implementation may be awkward for another. And what's good for users might be inconvenient for vendors. > The more I read this thread and ask questions, the more I get the impression > that the only reason this proposal is made is out of unfounded fear. It seems you are saying "give us guns, we won't use them". And I agree, probably you won't. But hey, I'm still not supporting the giving out of guns. > In reality applications will be chosen based on which subset of the features > of ODF they support, both loading+displaying and saving them. > So I fear that those governments that were told they need a 'strict > compliance' tool have been misguided. We weren't told. We pretty much figured it out for ourselves :-) > Using the ODF-Testsuite we would get > *much* more realistic results that show the compliance of the implementation. Agreed. Format compliance is just one step along the way towards interoperable applications. The rest depends on the consensus seeking around features which takes place between implementors on this committee. And there's no easy way round that. When I first joined this committee it was engaged in going through that detailed spreadsheet of application default settings. That exercise, unexciting as it was, impressed me greatly. A lot of effort, a lot of compromise, a lot of generosity, a lot of shared vision. That's what we need at this point. Just not too much generosity for an "extension" mechanism which will allow each vendor to clear the low conformance hurdle whilst maintaining their own application specific idiosyncrasies. Regards Bob > -- > Thomas Zander >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]