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] Agenda for August 15th ODF TC Teleconference meeting

Hi Patrick,

Patrick Durusau schrieb am 12.08.2022 um 23:03:


Comments below:

On 8/10/22 20:15, Regina Henschel wrote:

The specification of 19.600 table:condition, 19.600 table:condition, 19.639 table:expression and 19.646 table:formula already contains such a sentence. Under the proposed addition for 19.811 text:formula, all affected attribute descriptions specify which namespace to use when a prefix is missing. Therefore, this can be omitted in item D.3).

Not 19.600 table:condition twice, yes?

First one should have been 19.472 style:condition.

My proposal for item D.3) in 2.2.1 OpenDocument Document:
The specification of style:condition (19.472), table:condition (19.600), table:expression (19.639), table:formula (19.646) and text:formula (19.811) determines a namespace to be used for the attribute value. This namespace determines the syntax and semantics of formulas or expressions in the attribute value. If the namespace to be used is the "urn:oasis:names:tc:opendocument:xmlns:of:1.2" namespace, then the formulas and expressions shall conform to Part 4 of this specification.

But doesn't setting style:condition (19.472) to Part 4 change the meaning of:


Because the condition footnote() isn't defined in Part 4?

Please see in 19.472 style:condition itself, how the namespace is used.
There you find
"The XML namespace that applies to the style:condition attribute specifies the syntax and semantics of any /expression/ occurrences in the style:condition syntax."

The conditions that may be used by paragraph styles do not contain any /expression/. Thus style:condition="of:footnote()" is syntactically correct. But the bounding to _any_ namespace is meaningless, because the the attribute value "footnote()" does not contain an expression.

The situation is different for the attribute values which may be used by table cell styles. They are "cell-content() op value", "cell-content-is between(value1, value2)", "cell-content-is-not-between(value, value)" and "is-true-formula(expression)" And later it is defined, that "value", "value1" and "value2" can be an /expression/.

The namespace determined by the prefix or the default namespace is only applied to the /expression/.

The same construct is used in 19.600 table:condition. There too, the namespace is only applied to /expression/.

19.639 table:expression is different. It has
"The XML namespace name bound to the namespace prefix specifies the syntax and semantics of the formulas and values occurring within the condition." Because the structure only requires an '=' equal sign in case of a prefix and not other keywords occur, I would say, that the entire part after the '=' equal sign has to follow the syntax and semantics given by the namespace.

19.646 table:formula is similar to table:expression, only that is has not the special rule for a '=' equal sign. It has "The namespace bound to the prefix determines the syntax and semantics of the formula."

19.811 text:formula has "The text:formula attribute specifies the formula or expression used to compute the value of a field." and "The namespace bound to the prefix determines the syntax and semantics of the formula."

Since the individual attribute specifications use the terms "formula" and "expression", I tried to include both.

I have used the first paragraph in my proposal to indicate, that "formula" and "expression" are terms uses in the specification of the individual attributes. I thought that would be clearer than the current term "attribute value portions that are expressions determined by a prefix".

And none of the other conditions are so defined.



Not to mention that doesn't address our changing from "shall" support Part 4 (which was an error for style:condition) to some namespace with a default.


Thinking perhaps, not committed to this, that we should:

1) To Andreas' point, keep shall either use our namespace or default to it, but

2) May support other namespaces but that's not required for conformance, good for interoperability but allows conformance to remain as it is now.

In my understanding the current conformance clause 2.2.1 D.3) does not say, that the namespace shall be "urn:oasis:names:tc:opendocument:xmlns:of:1.2". But it says, _if_ the used namespace is "urn:oasis:names:tc:opendocument:xmlns:of:1.2", then syntax and semantic shall conform to Part 4.

For the table:formula attribute in Spreadsheet documents the namespace "urn:oasis:names:tc:opendocument:xmlns:of:1.2" is mandatory. That is in sections 2.2.4 D) and E).

We should consider to make the namespace "urn:oasis:names:tc:opendocument:xmlns:of:1.2" mandatory for Spreadsheet documents not only for table:formula attribute but for table:condition, table:expression and style:condition attributes as well, since evaluators need to know syntax and semantic to produce correct cell values.

Add in each of the five attribute descriptions:
Producer should only use the "urn:oasis:names:tc:opendocument:xmlns:of:1.2" namespace to ensure interoperability.

Producers .... yes?


Kind regards

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