Fwd: [office] Conformance Clause proposal, Version 8

[Bob Jolliffe <bobjolliffe@gmail.com>]

Forgot to copy to list ...


---------- Forwarded message ----------
From: Bob Jolliffe <bobjolliffe@gmail.com>
Date: 2009/2/7
Subject: Re: [office] Conformance Clause proposal, Version 8
To: dennis.hamilton@acm.org


Dennis,

2009/2/7 Dennis E. Hamilton <dennis.hamilton@acm.org>:
> 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?

I'm referring to the 9th iteration, where it states:

"10.8.2 table:formula

Add:

Within conforming spreadsheet documents, the namespsace prefix shall
be bound to the namespace
urn:oasis:names:tc:opendocument:xmlns:of:1.2, and the formula shall be
a conforming OpenDocument formula as defined by the OpenDocument
specification part 2: Formulas."

Perhaps I am misreading something.  Or you are referring to my stated
preference for a single conformance class.

As I have said somewhere earlier, though I would like to have seen a
single conformance, clearly this is not going to be easy to achieve
and I have thrown my weight behind Michael's proposal - 9th iteration
- which seems to represent a reasonable compromise.  And which I think
also addresses the question of  <style:*-properties> . I would still
hope that we might continue to work towards a unitary understanding of
an ODF document as this is what best serves our particular interest as
users in government.  Granted there is much more to interoperability
than restrictions on where foreign elements might be expected, but
unbridled licence to extend is something I fear.

I'll read back over the various comments which I have seen made about
"host language", though my current thinking is that it describes the
intent very well.

Regards
Bob

>
> 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 <style:*-properties> extensions in your
> requirement for some rigid conformance.  In or out?
>
>  - - - - - - - - -
>
> BACKGROUND ANALYSIS
>
> Here's all I was able to find:
>
> In Part 1, draft8, there is
>
> 18.1016 table:formula
>
>  ...
>
>   "Formulas allow calculations to be performed within table cells.
>   Every formula should begin with a namespace prefix specifying
>   the syntax and semantics used within the formula. Typically,
>   the formula itself begins with an equal (=) sign and can include
>   the following components: ... "
>
> I don't find anything normative here, other than a namespace prefix be
> included.
>
> In the OpenFormula 2008-12-21 draft, there is the following related remark
> under namespaces (keeping in mind that OpenFormula is meant to be embedded
> in other "host languages" than ODF):
>
> 1.3 Namespace
>
>   This specification defines a particular formula syntax that is
>   often contained in XML attributes. In this case, the attribute
>   value will typically begin with "="; normally the namespace
>   will not be referred to. However, it is legal to specifically
>   identify a namespace, and to include a namespace prefix in the
>   attribute. If this occurs, the "of:" is typically used, and
>   the following namespace is used:
>
>     urn:oasis:names:tc:opendocument:xmlns:openformula:1.0
>
>   For more information about XML namespaces, please refer to the
>   Namespaces in XML specification [xml-names]. Implementations may
>   also accept formula syntaxes other than OpenFormula, and they may
>   accept various compatible extensions to the default OpenFormula
>   syntax.
>
> I don't see anything that even suggests OpenFormula becoming the default in
> ODF (in the case of there being no prefix), but I assume that is an
> oversight in the ODF 1.2 Part 1 draft 8.
>
> 2. Conformance
>
> This is a lengthy section.  It provides for explicitly extensions in
> formulas, restrictions to specific groups, and a wide variety of other
> variations.
>
> With regard to OpenFormula and only OpenFormula, I think this paragraph is
> pretty clear:
>
>   Applications may implement subsets or supersets of this OpenFormula
>   specification. An application shall only claim to conform to a given
>   function, operator, or group if the application completely meets all
>   of its requirements as defined in this specification. Applications
>   may (and typically do) implement additional functions beyond those
>   defined in this specification. Applications may support additional
>   formula syntax, additional operations, additional optional parameters
>   for functions, or make certain function parameters optional when they
>   are required by this specification. Applications should clearly document
>   their extensions in their user documentation, both online and paper,
>   in a manner so users would be likely to be aware when they are using
>   a non-standard extension.
>
>   This specification's text is written as a description of the requirements
>   of an implementing application. However, documents (data files)
> containing
>   formulas can also comply or fail to comply with this specification.
>   Documents with OpenFormula formulas may use subsets or supersets of
>   OpenFormula. A document may reference a nonstandard function by name,
>   or depend on implementation-defined behavior, or on semantics not
> guaranteed
>   by this specification. Thus, this specification discusses what is
> required
>   for a document to assert that it is a *portable*document*. A portable
>   document shall only depend on the capabilities defined in this
> specification,
>   and shall not depend on undefined or implementation-defined behavior. A
>   portable document shall only claim to conform to a given group if the
> document
>   only depends on the capabilities of the given group.
>
> I'm not sure where claims of portability and the groups claimed to be
> supported are announced.
>
> Whatever the merits of this and the remaining conformance clauses, I don't
> see how there is a prohibition of extensions in conforming documents with
> regard to use of table:formula namespace prefixes nor in any of the
> provisions of the OpenFormula specification.
>
> -----Original Message-----
> From: Bob Jolliffe [mailto:bobjolliffe@gmail.com]
> http://lists.oasis-open.org/archives/office/200902/msg00080.html
> Sent: Friday, February 06, 2009 16:54
> To: dennis.hamilton@acm.org
> Cc: Michael.Brauer@sun.com; OpenDocument Mailing List
> Subject: Re: [office] Conformance Clause proposal, Version 8
>
> Dennis
>
> 2009/2/6 Dennis E. Hamilton <dennis.hamilton@acm.org>:
> http://lists.oasis-open.org/archives/office/200902/msg00078.html
>> 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 <style:*-properties> and metadata foreign elements
>> are handled in the outer level either way (although I don't think the
>> recommendation as to their preservation is wise.)
>>
>> Do you agree with Rob that this would exclude the RDF metadata?  I can't
> see
>> why.  I don't think RDF's provision for arbitrary vocabulary is thought by
>> anyone to be an extension of RDF.  This notion of extensibility does not
>> strike me as an extension of RDF, it is the very nature of RDF.
>>
>> Or would strict conformance exclude the use of table:formula values with
>> prefixes from QNames of foreign namespaces?  Similarly for scripts?  If
>> pressed, I would have to agree that those are extension points built into
>> the specification.  I'm not sure which way someone who wants to have a
>> strict ODF document would decide on this one.
>>
>> If you say that is the problem, I will abandon my preference of "strict
>> conformance" as ours to define.
>>
>> Bob?
>>
>>  - Dennis
>>
>> PS: Bob, I add you to these questions because I don't know, for the single
>> level that is the only one you are interested in, whether the things I'm
>> asking about are included or excluded in your view.  Do you currently
> grant
>> variances for certain namespaces or processors or do you regard the rules
>> for RDF metadata and for the QName prefixes in table:formula and script
>> codes as allowing permissible extensions, along with the
>> <style:*-properties> and the metadata ones.
>
> My understanding is that the rules for RDF metadata would permit
> "extensions".  Though I'm not sure if I would say it is a good idea to
> think of it as generic extension mechanism.
>
> 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.
>
> Regards
> Bob
>
> [ ... ]
>
>