RE: [office] Conformance Clause proposal, Version 8

[robert_weir@us.ibm.com]

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" <dennis.hamilton@acm.org> wrote on 02/06/2009 
09:37:33 PM:


> 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
> 
> [ ... ]
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>