Comment on 1.6 of 26300

Dennis E. Hamilton dennis.hamilton at
Sun Jul 21 17:44:14 CEST 2013

I assume that 1.6 is an instruction to processing at the application level, which is why it is necessary to know about the schema.  The XML processor is not expected to do that job.

I assume the same with respect to the RNG data model.  The application must be crafted to know when the strings of white space are to be allowed but ignored.

I do not assume that either form of ODF 1.0/1.1 1.6 (and its counterpart in ODF 1.2) is anything that is expected of the XML processor.

I think the question is, does this provision, however stated/repaired, require application behavior to accomplish?  If the answer is yes, then removal of the provision is a problem for ODF producers that introduce such white space based on the assumption that it is ignored by ODF consumers.  Normally, such a change is accomplished by making the change in a later version of the specification.  The effect is that ODF consumers will continue to ignore such white space strings long into the future while newer producers of the format will no longer produce it.

 - Dennis 

PS: None of this gets at the interesting case: What is to be done with white-space strings of a foreign element that is flattened by removing its start and end tags in order to preserve any contribution it may have to the text of a non-foreign containing element.  In this case, the consumer does not have schema information for the foreign element.  (I must check MCE for a possible solution that producers of the foreign element might provide.)

-----Original Message-----
From: sc34wg6-bounces at [mailto:sc34wg6-bounces at] On Behalf Of MURATA Makoto
Sent: Sunday, July 21, 2013 12:16 AM
To: SC 34/WG 6 mailing list
Subject: Re: Comment on 1.6 of 26300


2013/7/21 Dennis E. Hamilton <dennis.hamilton at>:
> I have no idea why that passage is in ODF 1.0/1.1 (before Errata changes to it).
> My only suspicion is that there was a desire allow arbitrary white space for pretty-formatting of XML and that was thought important.  The clauses in 1.6 are designed to avoid any situation where such white space would be considered not conformant ODF and also to avoid it being taken as text.
> The rule probably goes back to the beginning of ODF when the proposal was DTD based.

Actually, even if there is a DTD, XML processors are required to
pass whitespace text chunks to application programs.  So, I
think that this is misguided from the beginning.


> Since there is no DTD, I offered the replacement passage that appealed to the RNG Data Model to have the same effect, under the assumption that implementations are based on the schema, whether or not based on schema validation.
> I am not attached to any of this.  But to produce another Errata on it for any of ODF 1.0/1.1/1.2 at OASIS there has to be some assurance that removing the provision (in any of its forms) will not invalidate any conforming documents and consumers.
>  - Dennis
> I would not be surprised that custom XML processing was also done.  It was learned, for example, that META-INF/manifest.xml had unusual parsers for ODT documents and namespaces were not handled well.
> I haven't retested that for current releases, but you might find this report interesting:
> <>.
> There are more details here:
> <>
> with a description of the files here:
> <>.
> -----Original Message-----
> From: eb2mmrt at [mailto:eb2mmrt at] On Behalf Of MURATA Makoto
> Sent: Saturday, July 20, 2013 08:47 PM
> To: dennis.hamilton at
> Cc: SC 34/WG 6 mailing list
> Subject: Re: Comment on 1.6 of 26300
> [ ... ]
> When I read ODF 1.0, I thought that the section about whitespace
> is useless and should be simply deleted.  I still think so.
> I do not understand why ODF should say something about
> behaviours of XML processors.  I also think that most ODF
> implementations will not rely on RELAX NG or NVDL validation
> at run time and thus specifying whitespace processing in terms
> of validation is also useless.  ODF application programs may
> or may not remove some whitespace text chunks when there are
> sibling elements.  I do not understand why the ODF spec should tie
> the hands of implementors here.  The choice (i.e., remove or
> not to  remove) has nothing to do with interoperability of ODF documents.
> Regards,
> Makoto
> [ ... ]


Praying for the victims of the Japan Tohoku earthquake

sc34wg6 mailing list
sc34wg6 at

More information about the sc34wg6 mailing list