Re: [office] Agenda for August 15th ODF TC Teleconference meeting

[Regina Henschel <regina.henschel@libreoffice.org>]

Hi Patrick,

Patrick Durusau schrieb am 12.08.2022 um 23:03:
> Regina,
>
> Thanks!
>
> 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.

> > (B)
> > 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:
>
> style:condition="odf:footnote()"
>
> 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.

> > (C)
> > 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?

Yes.

Kind regards
Regina