OASIS Open Document Format for Office Applications (OpenDocument) TC

Back to discussions
Expand all | Collapse all

Conformance Clause proposal, Version 8

  • 1.  Conformance Clause proposal, Version 8

    Posted 02-05-2009 13:25 
    Dear TC members,

when I look over the discussions regarding the conformance clauses, it
seems to me that there is actually a very large area of consensus, and
that there are only a few, but essential items where the opinions
differ. These are:

- Should there be a loose conformance level for documents that allows
foreign elements everywhere?
- Can we remove that level, that we had in ODF 1.1, without prior notice?
- Should/Can we demand that a conforming producer must be able to create
(strictly) conforming documents?

In addition to this, there seems to be a strong demand for a conformance
level which does not allow foreign elements, and also for having a very 
limited number of conformance level. My impression is that we agree all 
agree on this.

The requirements are to some degree conflicting, but I anyway tried to
find a solution that may be acceptable to all of you. The key points of
it are:

- There will be two conformance levels for documents. One does not
support foreign elements and is called "OpenDocument document
conformance". The other one does support foreign elements without
restrictions and is called "OpenDocument Host Language Conformance".
- There will be two conformance modes for producers. A conforming
OpenDocument document producer must be able to produce conforming
OpenDocument documents. A conforming OpenDocument Host Language Producer
must be able to produce OpenDocument Host Language Documents, but there
is no requirement that it must be able to produce conforming
OpenDocument documents.

This proposals meets the requirement to have a strict OpenDocument
conformance, but it also provides a conformance mode for application
that wish to extend OpenDocument. This means that we have two
conformance levels rather than one, but the new name of what I called
"loose" conformance in prior proposals better reflects the
characteristics of this mode. And it lowers the risk of confusion. The
proposal also provides a conformance mode for ODF 1.1 documents that
contain foreign elements and shall be adapted to ODF 1.2.

The new name "OpenDocument host language conformance" is actually a name
I have adopted from the XHTML 1.1 specification, which provides a "XHTML
host language document" conformance level. It describes XHTML documents
that make use of extensions modules. In so far, we would be very close 
to XHTML in this regard.

The update proposal can be found here:

http://www.oasis-open.org/committees/download.php/31052/conformance-definition-proposal-v8.odt

The version I'm referring to is the first one in the document.

I have made a few non substantial corrections and clarifications, most 
of them have been suggested by Rob (Rob, thanks for having a close look 
at the proposal). A list of these changes can be found in the proposal 
itself.

I would be glad if this proposal is acceptable for all of you and would
like to discuss and maybe vote on it on Monday.

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


  • 2.  RE: [office] Conformance Clause proposal, Version 8

    Posted 02-05-2009 20:15 
    Michael,

I will examine the revision with great interest.  Thanks for your struggling
with this.

1. I favor the two-tiered approach, as you know.

2. I am assuming that the only schema will now be what has been called the
strict schema in the past.  That is an useful simplification.

3. I don't like the names very much, but that may be just me.

  3.1 For one thing, I have become fond of "strict conformance" and
"strictly-conformant."  I find that a powerful designation and I think it
aligns with the strong goals of those communities that establish
requirements for use of strictly-conformant ODF Documents in interchange and
for public and civil purposes.  It seems useful in branding, badging, and
for other purposes where documents are expected to be squeeky clean.  

  3.2 For the other, the term is simply too geeky and I don't think it helps
maintain a common understanding of what it is about.  I guess it means that
ODF is the host language for a customized version with limited extensions
(foreign elements being a circumscribed way of doing it, especially if the
underlying strictly-conformant ODF document is meant to be useful).  Is that
the sense you give it?  

4. I am not objecting to qualifying the term if it is as easy to convey as
strict conformance is and we are clear about the correspondence with
"conformant" in previous specifications.  [In thinking out loud, below, I
came up with "conformable" for the document, in contrast with the
strictly-conformant document, but producers would still be conforming and
strictly conforming, I think.]

5. Maybe we can kick this around for a few days in search of a better term.
If strict conformance is as appealing to others as I find it, maybe we just
use plain conformance in the sense it has for ODF 1.1 for now, with leaving
the search for a better term open.   

 - Dennis

 - - - - - - - - - - -

More thinking out loud -

Terms I rejected when thinking about this:

 - loose conformance (has the right tone, but can apply as easily to a
strictly-conforming consumer and producer)
 - weak conformance (same problem as above)
 - limited conformance (ditto)
 - modified conformance (again)
 - altered conformance (?)
 - custom conformance (sounds too much like a feature)
 - extended conformance (likewise)

If the words conformant and conformance are not used, or not used alone, so
there is no contraction that creates confusion with (strict) conformance and
(strictly) conformant, that might be more promising.

 - dialect
 - variant

[I am tempted to list "deviant," but we should save discussion about
deviations to apply to all deviations around fully-implemented
strictly-conformant documents consumed and produced by a processor.]

If there was a term that reflected how a strictly-conformant document is
obtained by reducing out the foreign matter, that would help too.  I thought
of "reduced conformance" but that is off base, even though it might be the
right kind of tone.

Oh, how about "conformable?"




    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


  • 3.  Re: [office] Conformance Clause proposal, Version 8

    Posted 02-05-2009 21:31 
    Michael

I like the solution you have proposed and will happily support it.  It
seems I am doomed to disagree with Dennis, but mostly I do like the
names.  The various forms of "wobbly"-conformance suffer from the same
weakness as implying, at least to the lay person, some sort of
sub-standard conformance.  Here there is no ambiguity.  Just
conformance.  I think that is at it should be.

I do agree with Dennis that "dialect" and "variant" might have some
potential, but thus far I'm in favour of the way you have it.

Dialectic conformance - a synthesis of contradictions - takes us down
a long-trodden path :-)

Regards
Bob

2009/2/5 Dennis E. Hamilton


  • 4.  RE: [office] Conformance Clause proposal, Version 8

    Posted 02-05-2009 22:07 
    Interesting, Bob:

In the 90 minutes or so since my note, I have become rather fond of having
conformable documents (the ODF 1.1 conforming document) and (strictly)
conforming documents, so that there is no sloppiness by which "conforming
document" can any longer mean anything but a "strictly conforming document."
I thought you would like that.

My biggest concern about moving conforming to strictly conforming as the
designation is the prospect for confusion with the older nomenclature.

Also, the emphatic nature of "strictly conforming" appeals to me, as I have
said, and I for one would like the term to have normative force.  (I will
probably use it anyhow, in my work.)

How's this for a compromise:

1. Use "conformable document" as the level that corresponds to the ODF 1.1
"conforming document" (assuming that OASIS allows us to name a conformance
class/target without using conformance in its name).

2. Use "strictly conforming document" as ODF 1.2 documents that comply
precisely with the schema (formerly the strict schema) and declare that
"conforming" is always a contraction of "strictly conforming" and none other
for ODF 1.2.

Some other touch-ups are required, but that is the key idea.  Of course this
also works if we simply use "conforming document" in (2), but I really like
the punch of "strictly conforming" along with (a) its giving normative
recognition to a common informal usage and (b) it making it emphatically
clear to users of the earlier specifications that there is a change in the
nomenclature that reuses some of the same words in a new way.

Can that work for you?

 - Dennis




    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


  • 5.  Re: [office] Conformance Clause proposal, Version 8

    Posted 02-05-2009 23:04 
    Hi Dennis

2009/2/5 Dennis E. Hamilton


  • 6.  RE: [office] Conformance Clause proposal, Version 8

    Posted 02-05-2009 23:14 
    In OASIS parlance, strict conformance means "conformance of an 
implementation that employs only the requirements and/or functionality 
defined in the specification and no more (i.e., no extensions to the 
specification are implemented).  I'd take that to mean without namespace 
extensions of course, but also without RDF metadata extensions, without 
office:meta extensions, without style:*properties extensions, etc.   It is 
probably worth preserving (or at least reserving) "strict" for that 
designation, even if we don't formally put it in release 1.2. 

Or think of it this way, if we allowed some kinds of extensions in strict, 
then what do we call a document that has no extensions? 

-Rob





From:
"Dennis E. Hamilton"


  • 7.  RE: [office] Conformance Clause proposal, Version 8

    Posted 02-05-2009 23:52 
    I'm assuming that the strictly-conforming document does exclude the
office:meta "extensions" (that is, via the non-strict "any" provision) and
the style:*-properties extensions (via the non-strict "any" provision).  I
would expect their continued occurrence would be at the conformable-document
level and that this shouldn't disturb those who rely on them.  I had hoped
and presumed that there would be only one (normative) schema and a
different, stricter schema would not be required (normative or not).

It is surprising to hear that the RDF metadata extensions are seen as
extensions of that sort.  I thought we were viewing the RDF metadata
extensions as extensions beyond ODF 1.1 (just as OpenFormula can be viewed
as an extension) and they are not an extension at all in 1.2.  All of the
necessary schema and enabling element and attributes seem to be defined as
part of ODF 1.2.  Maybe we should just call it RDF Metadata from now on and
integrate it into the document model appropriately, even though its
occurrence is optional.  

Is the problem simply that we have been using extension in a different way
than in OASIS parlance and we should simply clean up our nomenclature?

 - Dennis 




    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


  • 8.  RE: [office] Strict Conformance

    Posted 02-08-2009 20:04 
    Rob,

I have already conceded that strict conformance may not be desirable because
of the other connotations that might be implicit in the term, even if
defined specifically for Strictly Conformant ODF Document.  The following is
just background that I unearthed.

I was curious about exactly what OASIS thought extensions and strict
conformance were, so I did some searching.  

Your [1] came up very high in my search for ("strict conformance" OASIS).
From that I found the OASIS Conformance Requirements for Specifications v1.0
[2], Committee Specification 15 March 2002.  I notice that this document,
among others, is referenced in the current Guidelines to Writing Conformance
Clauses [3].  However, neither extensions nor strict conformance are called
out in the current guidelines.  Also, [2] does not seem to be normative for
[3] and that is worth pondering further at another time.

I see in [2: 8.1.2 Specifying conformance claims] that the only mention of
strict conformance is in this context:

    When a conformance claim is linked to extensions, the term 
    *strict*conformance* is often used. Strict conformance is 
    defined as conformance of an implementation that employs 
    only the requirements of the specification and no more.

I don't quite understand how that works, so I sympathize that using "strict
conformance" might lead to exclusion of more than is intended, especially if
we are not explicit or are uncertain about the extension points that there
are in ODF 1.2. 

It is also useful to see what there is in [2: 8.3 Extensions].

    An extension to a specification is a mechanism to incorporate
    functionality beyond what is defined in the specification. 
    Allowing extensions affects how conformance is defined as 
    well as what conformance claims may be made. Care should be 
    exercised in determining the extent to which extensions are 
    allowed or not allowed. Since extensions can seriously 
    compromise interoperability, specification writers should 
    carefully consider whether extensions should be allowed.

I would also add that the interoperability impacts can depend on the manner
in which extensions are allowed, not just on whether they are allowed or
not.

Here is a clarification of strict conformance that is perhaps more explicit
and explains why we are not going to use it (?) [2: 8.3.1]

    If a specification disallows extensions, then the conformance
    clause SHALL specify that extensions are not allowed and that 
    implementations of the specification SHALL precisely implement
    the complete specification. This is strict conformance. ...
    Note that this prohibition of extensions could be applied to a
    specific profile or level rather than to the entire specification.

The statement for allowed extensions [2: 8.3.2] is also intriguing.  

 - Dennis

[1] Robert Weir.  Re: Caution and Disclaimer on Interoperability.  Response
to Jose Lorenzo on the OASIS oiic-formation-discuss list, 2008-07-12,
available at


  • 9.  RE: [office] Conformance Clause proposal, Version 8

    Posted 02-05-2009 21:48 
    The strict versus loose conformance dichotomy is most typical used in 
cases where "loose" is the legacy format, including warts, and "strict" is 
a cleaner version that the committee defines.  XHTML and OOXML use it in 
that sense.  It isn't a statement about extensibility or the allowance or 
denial of extensions.  For example, both loose and strict OOXML allow 
extensions, while neither strict nor loose XHTML allow extensions.

But where you talk about extending an XML vocabulary with other name 
spaces, the practice is to call the vocabulary extended in that way the 
"host language".  By using that convention we would be following 
established practice, regardless of whether that practice is "geeky" or 
not.

In any case my preference remains to stick with a single conformance 
class, not permitting namespace extensions.  If we want to create a host 
language profile at some point, then that would also be fine with me, but 
we would need to address the kinds of issues I raised in my previous note 
regarding identification of executable code, personal content in 
documents, document assembly, referential integrity, etc.

Of course, by now everyone knows what Dennis and I think on the matter. 
Our votes will obviously cancel each other out.  So what really matters is 
what others on the TC think of the proposal.  I'll look forward to reading 
them on this list and in our call on Monday.

-Rob

"Dennis E. Hamilton"


  • 10.  RE: [office] Conformance Clause proposal, Version 8

    Posted 02-05-2009 23:10 
    Rob,

When you listed the evils of unbridled extension, I thought it was
over-reaching to attach all of those prospects to the presence of foreign
elements-attributes-values.  That is for two reasons:

1. If I wanted to attack a consumer and the assets of its user, I would not
do so with foreign e-a-v.   Since a consumer is likely to reduce those away,
it doesn't seem like the most-plausible choice for an exploit.  Of course,
if there is a prominent, widely-deployed consumer that has some supported
foreign e-a-v that is exploitable, that's perhaps more promising. 

2. If I wanted to construct an exploit, I would do it the same way it was
done in the past with Word, via the open and unprotected scripting, plug-in,
and macro capabilities.  Promising targets in ODF are fully available as
part of strictly conforming documents and I would go that route once an
implementation was widely-deployed enough to provide a profitable target.  

3. Likewise, if I wanted to connive a covert channel for smuggling
information or planting scurrilous information in a document, I would do it
using the available provisions of strictly conforming documents.

4. My sense of your objection is that poorly-designed foreign e-a-v and
their defective support by one or more consumers would expose those
consumers to additional prospects for such difficulties.  I can't argue
against that, as much as I hope that we are now much smarter about such
things than we were in the past.  

5. I do think that perhaps our efforts might be well-spent giving the same
careful scrutiny to existing exposures in strictly conforming documents that
you identify as important before considering any sort of host-language
profile:

    If we want to create a host language profile at some point,
    then that would also be fine with me, but we would need to 
    address the kinds of issues I raised in my previous note 
    regarding identification of executable code, personal content in 
    documents, document assembly, referential integrity, etc.

 - Dennis

PS: I just had a lot of fun searching through the uses of "script" and
"plugin" in the ODF 1.1 specification and in ODF 1.2 Part 1 draft 8.



    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


  • 11.  RE: [office] Conformance Clause proposal, Version 8

    Posted 02-06-2009 00:21 
    Dennis,  my critique is a bit more subtle than that.  The point is that 
extensions cannot be generically processed and that makes many common 
editing and document manipulations unsafe.

Consider some basic ODF:



Now suppose I am an ODF processor, say an editor and I want to split this 
into two.  Maybe the user wants to apply a different style to each word. 
Or I want to insert another word into this paragraph.  Doing all this is 
straightforward. 

Now suppose instead I have this:




What do I do, in an editor, if the user wants to remove one of those two 
words?  Or copy/paste both of them to another part of the document? Or 
split these two words into two different documents, or combine two 
documents with similar extensions?  What should I do? 

I the user does a copy/paste, do I end up with this?


.
.
.


That sounds reasonable, and is analogous to copying styled text.  But what 
if my-attr ended up being declared in the extension schema as an XML ID? 
I'd now have duplicate ID's,  Whoops.  Without knowing the extension, how 
do I know when to simply copy something versus when I need to generate a 
unique ID?  And that is the sample case.  More general cases will have 
multiple classes of reference semantics, possibly spanning multiple XML 
documents.

Without knowing the schema of the extensions, and the constraints 
expressed and implied I am at a loss.  Are there reference semantics?.  Is 
there an implied ordering?  Cardinality constraints?  I simply don't know. 
  You can't do generic editing of an unknown schema in a word processor. 
It just doesn't work.

So what happens in practice is one of two things:

A) The document extensions are understood by only the application that 
writes them, and other applications are forced to react by doing one of 
two things:

1) Automatically stripping out all extension markup just to be safe.  This 
obviously benefits no one, especially not the vendor trying to extend ODF, 
and certainly not the user who potentially suffers data loss.

2) Screwing up the document by trying to preserve extensions in a naive 
way, but actually messing up the integrity of the document by not 
understanding fully the constraints of the extensions schema.  This also 
is a disservice to the user.

or B) The document extensions are well-documented by the application 
extending the format, and other vendors implement the additional 
constraints required.  But in this case, if vendors agree on the semantics 
of an extension, then shouldn't this just be made part of the standard?

That is why arbitrary extensions are evil.  They create in general an 
interoperability problem that defies solution. That is why no ODF 
implementation today uses this feature.  And this is why I've recommended 
that it be removed from the standard.

-Rob

"Dennis E. Hamilton"


  • 12.  RE: [office] Conformance Clause proposal, Version 8

    Posted 02-06-2009 01:23 
    Rob,

Your particular examples here all strike me as having to do with the current
problematic statements about "preservation" of an unsupported/unknown
foreign element-attribute-value.  My presumption is that anything that
involves not knowing what to do with the foreigner under an operation means
the extension has to go away (e.g., begin and end tags disappear and the
content that is left is treated the same way by recursion).  Copy and paste
and not knowing if an attribute value is of type ID (or IDREF) is a great
example.   There is also the lifting out of an xmlns scope to be dealt with
under movement and under removal of unknown surrounds.

I'm all for not preserving stuff that is unsupported/unknown, and also not
preserving it, even when supported, as part of the operation of a
strictly-compliant producer.

With regard to ID type values, one would hope that xml:id is always used
when reference by fragment identifier is required and that other
interdependencies are handled by other than ID and IDREF type values.
(Although not material here, I wonder if the practice of using local names
id, ID, and maybe even ref came out of wanting to be able to know about the
ID and IDREF and IDREFS types without being in possession of the schema or
having access to even a DTD?)

It is also not possible to know that there are other unknown dependencies
between material that is touched in a foreign-erasing way and material in
other parts of the XML document that are not being touched.  That the
dependency will be broken strikes me as something that those who introduce
foreign e-a-v had better be prepared for.  (My example about layout hints in
my note to Bob is fraught with that.)

I think this is a great example of the care that is required for dealing
with foreigners (we need an internationally-inoffensive term for this) that
are not supported/understood, and implementers of foreigners need to be
prepared to encounter the consequence of such action in documents they
receive (back).

I will agree that some arbitrary extensions will be stupid.  Anyone who
introduces foreigners that are intended to be found in interchange needs a
good understanding of the likely treatment and the consequent mangling that
may be found in document that have recognizable foreigners.

I think your points about the hazards are all good ones and I think the
limitations on "preservation" need to be established better.  I don't have a
picture of how to handle that in the specification.  Maybe a technical note
on limits of preservation for foreign elements-attributes-values would be
better, especially since the limitations already apply to ODF 1.0/IS
26300/ODF 1.1 too.

 - Dennis



    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


  • 13.  RE: [office] Conformance Clause proposal, Version 8

    Posted 02-06-2009 19:18 
    "Dennis E. Hamilton"


  • 14.  RE: [office] Conformance Clause proposal, Version 8

    Posted 02-05-2009 23:10 
    Rob,

I don't mind describing the conformable (short for
optionally-carrying-foreign-elements-attributes-values) document as a case
of hosting features on an ODF document carrier, although I am not sure this
case is a precise fit.  I just object to it being the name for it.

I of course agree with your assessment of our respective perspectives and I
thank you for the background with regard to "loose" and other terms (having
overlooked that I use HTML 4.01 transitional as my HTML DTD of choice until
HTML 5 is baked).

 - Dennis 


    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


  • 15.  Re: [office] Conformance Clause proposal, Version 8

    Posted 02-06-2009 12:03 
    Hi Dennis,

On 05.02.09 21:14, Dennis E. Hamilton wrote:
> Michael,
> 

> 3. I don't like the names very much, but that may be just me.

I agree to Rob that we should reserve the term "strict" for something
that may even be more strict than what we have today.

The term "host language conformance" is a term that is used in other
standards, too, and that very well characterizes this conformance level,
without having to interpret terms like "strict" or "loose", which can
have many meanings. So, why not use an established and "speaking" term 
here? Our charter says we should borrow from existing standards where 
possible. Why not use a term that is used in other standards, too?

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


  • 16.  RE: [office] Conformance Clause proposal, Version 8

    Posted 02-06-2009 23:10 
    Out of curiosity, if strict were reserved for the one that means with no
extensions, what do you see that as leaving out?

I would think that the


  • 17.  Re: [office] Conformance Clause proposal, Version 8

    Posted 02-07-2009 00:55 
    Dennis

2009/2/6 Dennis E. Hamilton


  • 18.  Re: [office] Conformance Clause proposal, Version 8

    Posted 02-07-2009 01:47 
    On Sat, 2009-02-07 at 00:54 +0000, Bob Jolliffe wrote:
> The current proposal regarding prefixes in table:formula seems to
> quite clearly not allow extensions in conforming documents.   For a
> conforming document this is as it should be, to avoid incompatibility
> between spreadsheet applications.

I really see no chance of avoiding incompatibilities between spreadsheet
applications, considering the current draft of OpenFormula. Some (many?)
functions contain "implementation defined" results for at least some
possible arguments. Unless there is some verification mechanism to
ensure that those argument values cannot occur, the standard cannot
expect interoperability for conformant spreadsheet applications.

For example VLOOKUP a function in the "small" and so required by
virtually any implementation may expect the DataSource (one of its
arguments) to be sorted. But the sort order required may depend on
whether the application implements a separate "logical" type. If
DataSource is not sorted, the result is undetermined and
implementation-dependent. Since the same DataSource may be sorted for
one application and not another, I am not sure how one could expect
interoperability.  

Andreas

-- 
Andreas J. Guelzow
Concordia University College of Alberta


  • 19.  Re: [office] Conformance Clause proposal, Version 8

    Posted 02-07-2009 15:17 
    Andreas J Guelzow wrote:
> I really see no chance of avoiding incompatibilities between spreadsheet
> applications, considering the current draft of OpenFormula. Some (many?)
> functions contain "implementation defined" results for at least some
> possible arguments. Unless there is some verification mechanism to
> ensure that those argument values cannot occur, the standard cannot
> expect interoperability for conformant spreadsheet applications.

I don't think that's true. Nearly all standards have SOME 
implementation-defined behaviors.  Documenting them lets users know what 
to avoid.

Nearly all _REAL_ spreadsheets don't depend on the 
implementation-defined behavior in the first place.  I fully expect that 
typical spreadsheets _will_ interoperate just fine.  If there's a case 
where that's not true, _AND_ can be fixed, please help us identify them 
so we can try to fix it.

> For example VLOOKUP a function in the "small" and so required by
> virtually any implementation may expect the DataSource (one of its
> arguments) to be sorted. But the sort order required may depend on
> whether the application implements a separate "logical" type. If
> DataSource is not sorted, the result is undetermined and
> implementation-dependent. Since the same DataSource may be sorted for
> one application and not another, I am not sure how one could expect
> interoperability.  

But this only matters if you mix logical and number values in the same 
column, and then sort on that.  That is EXCEEDINGLY improbable, and 
wouldn't even make sense to most users.   Indeed, this possibility 
wouldn't even occur to most users, because many programs don't even 
permit mixing of data types like that. Typically a VLOOKUP will be on a 
column with one data type - typically Text (string) or Number - and as 
long as you use the same type consistently in a field column, this works 
just fine.

Which justifies my point.  Yes, there are some implementation-defined 
behaviors, in this (and nearly all other) specifications.  That lets 
users know what to avoid, and helps them create spreadsheet documents 
that DO interoperate.

--- David A. Wheeler


  • 20.  Re: [office] Conformance Clause proposal, Version 8

    Posted 02-07-2009 18:52 
    On Sat, 2009-02-07 at 10:16 -0500, David A. Wheeler wrote:
> Andreas J Guelzow wrote:
> > I really see no chance of avoiding incompatibilities between spreadsheet
> > applications, considering the current draft of OpenFormula. Some (many?)
> > functions contain "implementation defined" results for at least some
> > possible arguments. Unless there is some verification mechanism to
> > ensure that those argument values cannot occur, the standard cannot
> > expect interoperability for conformant spreadsheet applications.
> 
> I don't think that's true. Nearly all standards have SOME 
> implementation-defined behaviors.  Documenting them lets users know what 
> to avoid.
> 
> Nearly all _REAL_ spreadsheets don't depend on the 
> implementation-defined behavior in the first place.  I fully expect that 
> typical spreadsheets _will_ interoperate just fine.  If there's a case 
> where that's not true, _AND_ can be fixed, please help us identify them 
> so we can try to fix it.
> 
> > For example VLOOKUP a function in the "small" and so required by
> > virtually any implementation may expect the DataSource (one of its
> > arguments) to be sorted. But the sort order required may depend on
> > whether the application implements a separate "logical" type. If
> > DataSource is not sorted, the result is undetermined and
> > implementation-dependent. Since the same DataSource may be sorted for
> > one application and not another, I am not sure how one could expect
> > interoperability.  
> 
> But this only matters if you mix logical and number values in the same 
> column, and then sort on that.  That is EXCEEDINGLY improbable, and 
> wouldn't even make sense to most users.   Indeed, this possibility 
> wouldn't even occur to most users, because many programs don't even 
> permit mixing of data types like that. Typically a VLOOKUP will be on a 
> column with one data type - typically Text (string) or Number - and as 
> long as you use the same type consistently in a field column, this works 
> just fine.
> 
> Which justifies my point.  Yes, there are some implementation-defined 
> behaviors, in this (and nearly all other) specifications.  That lets 
> users know what to avoid, and helps them create spreadsheet documents 
> that DO interoperate.
> 

Is this column sorted:

FALSE
MAYBE
TRUE
TRUE
TRUE
UNLIKELY

It looks sorted to me, so I paste it into OO3.0 and Gnumeric 1.9.4 into
cells C1 to C6

I add the formula
=vlookup("MAYBE",C1:C6,1,1)

now the results are _not the same anymore. Gnumeric yields what I would
have expected: "MAYBE" while OO3.0 yieds "1" ??

Of course this has to do with the fact that the internal representation
of the pasted column differs between the two. (You can see this when you
save it in OO3 as an ods file and open it in Gnumeric (ignoring the
warning messages gnumeric brings up regarding the file format). You
can't save it as a gnumeric file and open it in OO3.0 since OO can't
handle that.)

But you really think that your typical user can understand these
restrictions on the range or just thinks that the implementation defined
answer makes really sense? See for example the second problem listed
in  
http://bugzilla.gnome.org/show_bug.cgi?id=567389

Andreas 



-- 
Andreas J. Guelzow
Concordia University College of Alberta


  • 21.  RE: [office] Conformance Clause proposal, Version 8

    Posted 02-07-2009 02:38 
    Bob,

I can't find anything that pertains to limitations on formulas table:formula
with regard to conforming documents.  Is there some proposal separate from
version 8 of the Conformance Proposal, the ODF 1.2 Part 1 draft 8, and the
OpenFormula 2008-12-21 draft?

Requiring prefixes doesn't seem to prevent extensions at all, since the
namespace is not required to be one defined by the OpenDocument or
OpenFormula specifications.  This seems to be clearly recognized in ODF
1.0/IS 26300/ODF 1.1 and the current drafts of ODF 1.2 and OpenFormula.
(All implemented ODF spreadsheet documents I have ever seen use a "foreign"
namespace for the prefix in table:formula values.  That's one reason I asked
if you were granting variances to products, at least until OpenFormula shows
up in implementations.)

Please take another look or point me to the proposal you mean.  

 - Dennis

PS: I agree about RDF extensibility not having anything to do with
extensions to ODF (although some processor might do something aggressive, it
appears to me that the ODF Document stands on its own no matter what the RDF
is).

PPS: Where do you place the


  • 22.  RE: [office] Conformance Clause proposal, Version 8

    Posted 02-07-2009 16:37 
    The OpenFormula and Packaging parts are still being edited.  Once we get 
the draft of the core part done, we'll undoubtedly have a conformance 
discussion relative to each of the other parts as well, since each part 
can define its own conformance requirements.  But I would expect 
OpenFormula to feature prominently as a requirement.  That is why it was 
created.  I think the feedback on ODF 1.0 not having a defined formula 
language was unequivocal.

And I'd note as a curiosity, that OOXML neither allows arbitrary namespace 
extensions, not alternative formula languages, though we've seen in recent 
weeks a number of people who were vocal advocates of OOXML, now franticly 
scurrying around worried that ODF might actually become interoperable by 
making some of these same logical decisions.  Personally, I think their 
worry is well-founded.  ODF 1.2 will become more interoperable.  But I 
fail to see this as a liability.

-Rob

"Dennis E. Hamilton"


  • 23.  Spreadsheet Formula Conformance - Please Not Now

    Posted 02-07-2009 18:14 
    Whoa!

I just received an off-list note pointing out that Iteration 9 of the
Conformance Proposal (in version 8 of the document,


  • 24.  Re: Spreadsheet Formula Conformance - Please Not Now

    Posted 02-08-2009 17:39 
    "Dennis E. Hamilton"


  • 25.  RE: [office] Re: Spreadsheet Formula Conformance - Please Not Now

    Posted 02-08-2009 20:04 
    Rob,

I don't dispute the need to tie together the conformance interdependencies
of the parts of the ODF 1.2 specification.  I dispute the need to do that
now using normative pretend language appealing to other normative pretend
language that has not been written yet.  I find this particular approach to
"bootstrapping" makes us appear to be careless (or worse), leaving us with
defects that we have to remember to watch over and deal with in future
stages.  I would rather not do that.

Modifying the section on table:formula is unnecessary at this point, and it
will require its own deliberation when the time comes.  Attempting to
address it now is wasted effort and a distraction, in my opinion.  Also, the
new-born (February 5) proposed addition isn't a sufficient way to establish
the desired conformance and I don't think we should figure out how to repair
that as part of the current proposal.  I note these deficiencies: there
being no schema for table:formula in anything like the usual sense, the
addition being inconsistent with other parts of the same section, the
statement mentioning a conformance target that does not exist in normative
language of the very same conformance proposal, and asserting dependencies
on normative provisions of the OpenFormula specification that do not exist
at this point.  That's in addition to (1) the addition instructions being
incomplete and naming the wrong specification section along with (2) no
consideration of the use of table:formula within


  • 26.  RE: [office] Re: Spreadsheet Formula Conformance - Please Not Now

    Posted 02-08-2009 21:56 
    "Dennis E. Hamilton"


  • 27.  RE: [office] Re: Spreadsheet Formula Conformance - Please Not Now

    Posted 02-09-2009 06:21 
    Here's the thing Rob,

This is the statement that was made on Thursday about wanting review and
possible voting on #9 in document version 8


  • 28.  RE: [office] Conformance Clause proposal, Version 8

    Posted 02-07-2009 00:16 
    I would really like a simple adjective.  I understand the concept, I just
don't think it is usefully applied as a name for a conformance level.  I
also don't think it means anything until defined specifically as a
conformance level for ODF, so it is no better than "loose," just different.
I'm note even sure how to use "host language conformant" in a sentence.
I'll go review your use of it and see how it reads.

Have you seen it used as a defined level of conformance by anyone (as
opposed to talking about such kinds of conformance)?  My concern is that
this is not an established or "speaking" term in the community for which it
needs to be understood for ODF.  Are you going to make a normative reference
to another standard (I think that is what borrowing means, like using
ISO/IEC conformance nomenclature).

I'm still arguing for conformable (which is suggestive of the situation,
where in a hosted thing, you're not expected to be able to ignore the new
elements and it probably have to identify the hosting in some way) at the
ceiling and (strictly) conforming at the stricter level.  If strict is not
usable because it is a term of art in OASIS specification (although we are
not following the document that uses that definition), I'll give up about
that.  But I bet strict conformance sticks in popular use, even though
informally.  I also think you'll here people talking about OpenDocument
conformance (without the "document").

 - Dennis

OK: I am starting to repeat myself only louder.  I'm sticking to my
perspective that the term lacks any particle of explanatory power, and if a
reference to a definition has to be made in every occurrence it is simply a
bad idea.  But these are my last questions on this particular aspect.


    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message