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

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

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


Subject: RE: [office] Conformance Clause proposal, Version 8


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: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

[ ... ]



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