All extensions and root components should be required to have namespaces to avoid collisions IMHO.
----- Original Message -----
From: <>
To: <>
Sent: Sat Feb 07 08:38:54 2009
Subject: RE: [office] Conformance Clause proposal, Version 8
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" <> 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:]
> 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
>
> [ ... ]
>
>
> ---------------------------------------------------------------------
> 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
>
---------------------------------------------------------------------
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
