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 Andreas,

On 13.08.22 17:57, Andreas J Guelzow wrote:
On 2022-08-13 8:32 a.m., Regina Henschel wrote:
Andreas J Guelzow schrieb am 11.08.2022 um 04:07:

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".

i agree with Regina, as detailed below.

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.

I read this as that the conformance clause provides only two options.

i read it as specifying the 2 cases where the conformance clauses of part 4 are essentially "included" into part 3, and not saying anything about other cases.

if clause 2.2.1 D.3) would require part 4 to be used in these attributes, then clause 2.2.4 D) would be superfluous.

... apparently the 2.2.1 D.3) wording came in with this issue:


previously (as quoted in the mail linked from the issue) it had a similar structure, specifying 2 cases, while not saying anything about other cases:

"If the namespace prefix ... is associated with the [PART4] namespace, or if a namespace prefix is omitted ..., the syntax of any formula which is contained in the values of these attributes shall conform to [part 4]."

so it looks like the intent is to disallow using this namespace URL with other semantics than those specified in part 4, but there is no requirement beyond that.

(interestingly, Dennis Hamilton proposed a single sentence for both cases at first, but it was considered too difficult to read, so now we have 2 sentences.)

going further back, see also the description here:


where Dennis wrote:

"1. Formula namespace determination:
New clause (D1.4.3) establishes that the default syntax and semantics of formula-valued attributes is in accordance with the OpenFormula specification. In the absence of an explicit Namespace Prefix at the beginning of the attribute value, the OpenFormula Namespace shall be the default. Note that OpenFormula is not required, it is the default in the absence of a prefix that is bound via namespace declaration to something other than the OpenFormula Namespace."

Moreover, since the document cannot be interpreted reasonably without the consumer being able to understand these attribute values the third option cannot be acceptable.

As I mentioned in the meetings, using a differnet name-space is akin to using foreign elements. So it should at most be allowed in conforming Extended OpenDocument Documents.

this is of course a reasonable position to take, and i have some sympathy for it, but we should be aware that this would be a material change from the status quo on conformance.



Michael Stahl
Senior Software-Entwickler LibreOffice
allotropia software GmbH
Flachsland 10
22083 Hamburg
Registered office: Hamburg, Germany
Registration court Hamburg, HRB 165405
Managing director: Thorsten Behrens
VAT-ID: DE 335606919

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