OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office-formula message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [office-formula] Portable "documents"


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:
> Hi Patrick,
> On Tuesday, 2009-12-15 08:59:27 -0500, Patrick Durusau wrote:
>> My major concern at present is what to do with the notion of "portable  
>> documents."
>> [...]
>> Second, in order to fix the current difficulty, I really need to have  
>> the formula SC and ultimately the ODF TC agree on what is meant by  
>> "portable document."
>> To illustrate, I think Rob's initial suggestion of thinking of  
>> conformance as being divided between expressions and evaluators provides  
>> part of the superstructure I need to parse out the various threads of  
>> shall, may, required (sic), etc. in the current draft.
>> However, I understand "portable document" to cut across whatever  
>> conformance classes (I assume for example, large group conformance for  
>> expressions includes supporting the syntax of all fo the large group  
>> plus the lesser groups, but that medium group conformance for  
>> expressions is something less than that), but is not itself a  
>> conformance class. Yes?
> 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?

 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

Level 2 - conforms to small group and beyond X portable constraints

Level 3 - conforms to medium group and only to portable constraints

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.

But that is the nature of standards. We have to state a rule, may not 
always be the best rule, but it is the one we have chosen. Can't sit on 
the fence. (Sorry, Americanism, means to not choose one side or the other.)
>> One aspect of the editorial work, once the "portable document" issue  
>> (and whatever it should be called) is decided, will be how to best  
>> present that information for a standard. I certainly think it should be  
>> captured but if it isn't normative behavior, that pushes in the  
>> direction of a non-normative annex.
> No, I don't think so. The portable constraints belong to the functions.
Well, some of the "portable" constraints may properly belong under the 
functions, it really depends one how we decide to treat them.
>> Which would have the additional  
>> advantage of centralizing all the information that developers or even  
>> users would need when striving for or evaluating what is possible with a  
>> "portable document." As it stands now, they would have to search the  
>> entire document to piece together a (hopefully) coherent and consistent  
>> picture of what constitutes a "portable document."
> Currently they have the information present at the functions they use
> and don't have to jump back and forth or read material for features they
> do not use. We may consolidate general information about portable
> documents, not related to specific functions or features, in a section
> of its own, but not rip the function specific portable bits out.
You may be right about leaving portable bits under functions, although I 
seem to recall that some functions have comments about portability that 
aren't related to those functions. Will have to check on those.

Hope you are at the start of a great day!

>   Eike

Patrick Durusau
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) 

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]