Features, abstract features, and precise element semantics to limit lock-in

[jose lorenzo <hozelda@yahoo.com>]

--- On Mon, 6/23/08, robert_weir@us.ibm.com <robert_weir@us.ibm.com> wrote:

> From: robert_weir@us.ibm.com <robert_weir@us.ibm.com>
> Subject: Re: [oiic-formation-discuss] Deliverable: odf-diff?
> To: oiic-formation-discuss@lists.oasis-open.org
> Date: Monday, June 23, 2008, 11:49 AM
> Radoslav Dejanović <radoslav.dejanovic@opsus.hr>
> wrote on 06/23/2008 
> 05:41:10 AM:
> 
> > Dave Pawson wrote:
> > 
> > > An app that doesn't implement a 'may'
> clause isn't at fault
> > > and should not be penalized for that decision.
> > > Hence 'if implemented':
> > >   run the test
> > >   Display the result (but not as a pass/fail)
> > 
> > If I understand Shawn correctly, the idea is that a
> "may" clause means
> > that the application is not obliged to use that rule,
> but if it does,
> > then it must follow the spec.
> > 
> > In that case, test results would be:
> > 
> > a) not implemented - the application does not
> implement that clause
> > 
> > b) pass/fail - the application does implement that
> clause, but it does
> > or does not fully follow that clause specification.
> > 
> 
> There are really multiple levels here.  We must keep them
> straight.
> 
> First there is the feature level.  Some features are
> optional, some are 
> mandatory.  Every ODF document must be valid to the ODF
> schema.  This is a 
> mandatory requirement.  But support for spreadsheet
> formulas is optional. 
> For example, if you are writing a word processor, then
> spreadsheet 
> formulas would not be implemented.  Similarly, a very
> simple spreadsheet 
> might not have charts.
> 
> Then there is conformance at the level of a feature.  If
> you implement a 
> particular feature, such as the Zip packaging model, then
> some things are 
> required and some things are optional.
> 
> We can work within this framework in several ways.  For
> example, if we 
> define a mobile ODF profile, we can define exactly what
> features are 
> required for an implementation to claim conformance with
> that profile.  We 
> can also reduce the range of variability at the feature
> level.

First, I don't think "feature" has been defined. This might become an important definition (not sure for which TC).

*****

Second, I want to bring up something related that was discussed lightly a while back to see if more comments surface at this time.

ODF can say something like "feature X is required for profile Y." This is like part of what you are talking about above. It might be like saying that the "text:p" element must be supported in ODF/core.

Also, "feature X, if implemented in profile Y, requires Z to also be implemented." This is also what you are talking about in the case of conditioned requirements. You used the zip example saying that, if implemented, some other items would have to be implemented also.

What is not mentioned here is "if *abstract feature* x is implemented in profile Y, it must be implemented using the feature X of profile Y." The point here would be to define "abstract feature" at a high level while "feature" is defined as a set of XML components with associated semantics. The idea would be to say (to use an example of a paragraph) "if paragraphs are implemented in ODF/core, they must be implemented using the text:p feature of ODF/core."

This can be tricky to get right, but it's something that some might want to think about to see if an elegant breakthrough solution or insight appears.

It should not be necessary to state this if the profile is strict enough, but for cases where you want to allow extensions (perhaps limited in some way or not), you may want to specify this sort of constraint in order to at least somewhat guarantee that (eg) two people writing prose will be able to see the base of each other's work if perhaps one won't see various markup present through extension tags only viewable in the other's app; thus, the more basic app won't show the "notes" element or the "reminds-me-of" element or the "to-do" element, but it would show all the paragraphs since these would have to be inside text:p.

Note, that this is different from the round-trip super features examples given by marbux. It's about saying that you won't be following the ODF/X profile if you place what is well known conceptually as a paragraph into anything but the text:p. Yes, the profile may allow for extensions, but you would not be able to hide normal paragraph text within those extensions to hide them from other applications. -- I know this is one of those "beware of the big vendors" issues with which some of us are allegedly overly preoccupied, but it's still a real interop issue any way you slice it. Where this able to be placed in ODF, it would help with interoperability by clearly defining another area of undesired app behavior as "illegal" in the sense of failing to meet interop conformity requirements.

Though it may be a challenge to get this correct, it may actually be as simple as stating things much as is done in the paragraph example above. The hard part is probably to define things carefully and account for all relevant details.

So, to expand on the paragraph example, "paragraph" is a notion that is millennia old I think, so we should be able to use a dictionary definition in here to help us and have everyone understand. We'd have to specify the scope (eg, paragraphs as pictures may have to be treated specially somehow or may be out of scope) and deal with other possibly tricky details.

*****

[Third..] A related item is to define carefully the semantics of text:p. For example: "All content of text:p must be "paragraph" content (as understood by dictionary def of 'paragraph' term) or content the user designated or intended to designate as a paragraph." In this way, an app would be "prohibited" from creating interop problems by using text:p as a storage element with crazy semantics (eg, to hold information about the app session or undo history). ["Prohibited" means that it would fail to be (eg) conformant.]

Perhaps only some profiles would be specified strictly as just mentioned.

*****

If we combine these two items: stating that paragraphs must be implemented as text:p and stating that text:p must only include paragraphs; then we have a clear rule for catching a large number of attempts to violate the rules for lock-in.

Note the difference with how ODF stands now. The abstract concept of a paragraph is not clearly defined nor used within any constraint, either to say that a "paragraph" must use text:p, or that text:p must contain nothing but a single "paragraph". [At least I don't think I came across this in skimming ODF 1.1]

Dave (and others), I know there is the testability issue; however, there is such a thing as damage control after the fact. An accreditation group may want to be able to revoke certification if they are led to believe that a product has been violation these constraints repeatedly or simply because it is buggy. After all, a user that wants to write a paragraph for their resume wants to be able to read it back when they open it with last year's app or in a different app that is also certified as meeting profile ODF/core.

Yes, it is not completely subjective. That is why I refer to *abstract* feature. However, it is a useful notion because the concept of a paragraph is very well defined in other contexts. It's understood by humans if not precisely in some contexts by computers. [Well, even humans might debate the meaning of paragraph.. which is why I wanted to throw in the "intent of the user as designated by their actions." I think some W3C standards also make use of such potentially vague untestable notions. ..And I am talking about trying to get this into the ODF normative sections.]

Manual tests requiring subjective human decisions are fine if the ratio of tests performed to human interaction is still high, and we can help make the decisions as unambiguous as possible.

Think of the process a cert body might go through to "verify" an identity: it might involve very subjective items, interviews, etc. Some things just can't be made into simple objective tests with current state of the art, but that doesn't mean these subjective tests aren't useful or aren't being made a part of rigorous authoritative processes.

Those writing the official standard must always determine how much to enshrine and how much to leave to third parties. I think the more items, well thought out and well worded, that we can add to ODF, the more useful it will be in the marketplace since more groups will be able to build business around it, have confidence in it, have it perform to expectations, etc.