[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Rules for handling parsing errors (was: proposal for ODF 1.2:extension of verticalrelationvaluesfor certain anchor types)
Hi Michael, Well lets discuss this in the next TC call then. Wrt. to Olivers proposal the interresting question is what do we expect todays readers to do with it... When I read the current ODF spec it seems to me that the document is simply not conformant and thus everything can happen.... Anyway: Was just curious whether we say something somewhere in the spec about invalid values already. You may wanna take a look at "Rules for handling parsing errors" of the CSS spec: http://www.w3.org/TR/2007/CR-CSS21-20070719/syndata.html#parsing-errors It would be great to have something similar in ODF. E.g. when we would use the CSS rules for handling parsing errors the answer to the backward compatiblity question of Olivers proposal would be very easy: <quote>Illegal values. User agents must ignore a declaration with an illegal value.</quote> So it would treat the positions as if none was given. HTH, ~Florian >>> Michael Brauer - Sun Germany - ham02 - Hamburg <Michael.Brauer@Sun.COM> 07/04/08 11:03 AM >>> Hi Florian, Florian Reuter wrote: > 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 Its an interesting question whether the ODF specification should require a particular behavior here, and if so which, or whether it should be implementation dependent what an ODF 1.2 application does if it encounters a value that is defined in ODF 1.3 (or 2.0) only. There is actually nothing we can do here for ODF 1.1, since ODF 1.1 is finished already. The behavior of an ODF 1.1 application is actually implementation defined. Anyway, as you said already, it is also a general question that does not effect Oliver's proposal only, but all past and future proposals. I therefore suggest that we proceed with Oliver's proposal independent of this discussion. If you like, you may of cause elaborate the topic further. BTW: My understanding of Oliver's proposal is that it simply allows a combination of two attribute values (of two attributes) that were not allowed before. The attributes and there values do exist already. Therefore it would not be sufficient to state what an application should do if it encounters invalid values, but you would also have to define how it should behave if there is an illegal combination of attributes and values. That's a for more complex task. Best regards Michael -- Michael Brauer, Technical Architect Software Engineering StarOffice/OpenOffice.org Sun Microsystems GmbH Nagelsweg 55 D-20097 Hamburg, Germany michael.brauer@sun.com http://sun.com/staroffice +49 40 23646 500 http://blogs.sun.com/GullFOSS Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer Vorsitzender des Aufsichtsrates: Martin Haering
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]