[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] proposal for ODF 1.2: extension of verticalrelationvaluesfor certain anchor types
Hi Patrick, I guess our question was a little bit too narrow. The question is rather simple. The general question is: What is an ODF app supposed to do if it encounters an invalid value for an attribute. E.g. the CSS specification says that if a CSS property has an invalid value a CSS app should treat the property as if it was not there. So what shall an ODF app do? Options: a) Treat it as if the attribute was not there b) Try to preserve the value c) Treat is as if the attribute was there but overwrite the invalid value with a "default" value ~Florian >>> Patrick Durusau <patrick@durusau.net> 07/03/08 3:43 PM >>> Oliver, I am trying to catch up on various threads, a question below: Oliver-Rainer Wittmann - Software Engineer - Sun Microsystems wrote: <snip> > But regardless of my proposal and as you already stated, we have the > problem that the current ODF 1.0/1.1 specification does not define, how > an application should react, when a disallowed combination of vertical > relation and anchor type occurs in a document. The other problem we have > is that there exist already released ODF 1.0/1.1 supporting > applications, which based on the above mentioned undefined behavior. > Each of the Florian's above given behaviors and even more ones can > already been implemented. > Thus, I have problems in defining the behavior of an ODF 1.0/1.1 > supporting application, when it imports an ODF 1.2 document containing > one of my proposed new combinations of vertical relation and anchor type. > > I think we have no chance to correct our error - leaving the behavior on > disallowed vertical relation and anchor type combinations undefined - > for ODF 1.0/1.1 supporting applications, especially when these > applications are already released. That is the reason why I only made > assumptions about it. > What we can do - and at the beginning I already stated that it seems to > me a valid request - is to correct this error for ODF 1.2 supporting > applications. But, I think this is not in the scope of my proposal, > which is a feature proposal. The correction should be handled in a > different proposal - a correction proposal - in order to have the > possibility to discuss/vote on these things separately. > Here is where I jump the track. I have: 1) Your post on extending vertical relation values for certain anchor types (1 July 2008) 2) Florian responds (3 July 2008) asking about "old ODF processing entities" 3) You respond as above suggesting "something" is a valid request. 4) Following #3, Florian further responds with a question about invalid/unknown values for known elements/attributes. What I am missing is the "second" proposal that you see in Florian's post. Do you mean the request that we somehow codify the treatment of values that we did not previously define? While that may appear to make sense, I am not sure how that is different from defining the "next" version of the standard. In other words, if previously we did not define the vertical relation values you propose, we can say in ODF 1.2 (as a separate proposal) that if a document doesn't have these values, we define default values to be applied. Assume we are talking about an ODF 1.0/1.1 document. An application claim conformance to ODF 1.2 in that respect. However, note that I don't think it is possible for us to re-define what it would mean to be a conforming ODF 1.0/1.1 application. Whatever conformance we defined in those versions of the standards is fixed and cannot be changed. I suppose, just to be complete, that someone could separately define a profile for ODF applications that relies in part on one of the ODF standards and says that in addition to supporting parts 1 - * of the ODF standard, an application shall, ....., and define additional requirements for things that ODF does not define. I can easily imagine vertical industries that create metadata vocabularies, such as for medical intake forms, etc., creating such profiles. Which would enable them to require the use of ODF and some specified metadata vocabulary. Or to use it in some particular way. The important thing to note is that would not be the ODF TC per se making that declaration. Hope you are having a great day! Patrick -- Patrick Durusau patrick@durusau.net Chair, V1 - US TAG to JTC 1/SC 34 Convener, JTC 1/SC 34/WG 3 (Topic Maps) Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300 Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps) --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and 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]