[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] Conformance Clause proposal, Version 8
All extensions and root components should be required to have namespaces to avoid collisions IMHO. ----- Original Message ----- From: robert_weir@us.ibm.com <robert_weir@us.ibm.com> To: office@lists.oasis-open.org <office@lists.oasis-open.org> 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" <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 > --------------------------------------------------------------------- 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]