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 <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:]
http://lists.oasis-open.org/archives/office/200902/msg00080.html
Sent: Friday, February 06, 2009 16:54
To:
Cc: ; OpenDocument Mailing List
Subject: Re: [office] Conformance Clause proposal, Version 8
Dennis
2009/2/6 Dennis E. Hamilton <>:
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
[ ... ]
