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

["andreas.guelzow" <andreas.guelzow@concordia.ab.ca>]

This exchange should have been on the list.

Andreas

Sent from my Galaxy

-------- Original message --------

From: Regina Henschel <regina.henschel@libreoffice.org>

Date: 2022-08-13 08:32 (GMT-07:00)

To: Andreas J Guelzow <andreas.guelzow@concordia.ab.ca>

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

Hi Andreas,

your mail did not go to the list, but wording indicates, that is was
intended for the list. In that case you can forward my answer to the list.

Andreas J Guelzow schrieb am 11.08.2022 um 04:07:
> Hi,
>
> I appreciate Regina's suggestion of a compromise but it still widens
> what is considered a conforming OpenDocument Document. I have no issue
> with widening the definition of a conforming OpenDocument Extended
> Document but I still think that interoperability with respect to
> conforming OpenDocument Document should not so completely depend on the
> goodwill of the implementers.

I do not see, that it widens the current definition of "conforming".

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.

There exists a "shall" in regard to table:formula attribute and
Spreadsheet Document. That is sections 2.2.4 D) and E).

>
> In any case, we still need to describe how a consumer is supposed to
> handle an unknown namespace prefix. Clearly, omitting the whole element
> containing the attribute whose value has the unknown prefix will lead to
> broken style references and other very undesirable side effects.

I agree, that we should say something about how a consumer should handle
unknown namespaces. Such statement does not belong to section 2.2.1,
which is about the document file, but to the specification of the
individual attributes.

There exist already such rule for 19.472 style:condition, "If a consumer
does not recognize a condition, it shall ignore the <style:map> element
containing the condition."


The table:condition attribute describes an action on cell content
changes by the user. That is not relevant for a consumer, thus I suggest
"If a consumer does not recognize a condition, it shall ignore the
<table:content-validation> element."

For table:formula attribute, table:_expression_ attribute and for
text:formula attribute I suggest:
"A consumer shall make the user aware, if it could not interpret some
content."
Such awareness could be e.g.:
* Opening the document initially readonly without any recalculation
using an office:value attribute or the character data content of the
element which has the attribute.
* Producing an error message in places where the attribute value is used.
* Use the office:value attribute or the character data content of the
element which has the attribute and in addition inform, that the related
formula or _expression_ could not be evaluated.
* Producing a general warning on opening in case the file uses unknown
namespaces.
What is possible or useful as "awareness" depends on the way a consumer
parses the markup and on the kind of consumer.



For table:formula attribute in Spreadsheet documents the
"urn:oasis:names:tc:opendocument:xmlns:of:1.2" namespace is mandatory
and reactions of evaluators on parts it cannot evaluate are already
handled in Part 4. As far as I have found, it is showing an error message.

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.

Kind regards,
Regina