[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office-formula] Portable "documents"
On Tue, 2009-12-15 at 21:24 -0500, Patrick Durusau wrote: > I have been out most of the day but I wanted to reply to at least one > formula post before closing down for the night. > > Eike Rathke wrote: > > > > Correct. A portable document and the portable constraints mentioned for > > functions are document author guidelines, not implementor conformance > > clauses. The portable term reduces a feature or function to a common > > denominator implemented by existing applications. New implementations > > should strive for more that usually is expressed as 'should'. If > > a document is not restricted to portable constraints it does not mean > > that the document is not conforming. > > > > > OK, say I have an evaluator that conforms to the "small" group of functions. > > How does that differ from an evaluator that conforms to the "small" > group of functions *and* only supports portable documents? That is simply not possible. An evaluator that conforms to the "small" group of functions cannot only support portable documents: Take the DATE function. To conform the evaluator must be able to construct a date from year, month, and day of month for any integer year, integer month and integer day. There are no constraints for those items. On the other hand DATE has portable constraints. So there are non-portable documents that any evaluator conforming to the "small" group of functions must support. > > From a conformance standpoint? > > In other words, it sounds like the "portable" constraints are creating a > subset of a larger set requirements, to which an evaluator could conform. > > Is there some reason to not say: > > Level 1 - conforms to small group and only up to portable constraints impossible > > Level 2 - conforms to small group and beyond X portable constraints the second part follows from the first for some X>0 > > Level 3 - conforms to medium group and only to portable constraints impossible > > etc. ? > > It seems me, and I may be wrong, that the current draft wants to state a > rule but then doesn't, or at least doesn't want it to be a hard rule. The portable constraints are just guidelines for users... > Andreas -- Andreas J. Guelzow, PhD, FTICA Mathematical & Computing Sciences Concordia University College of Alberta