Comment on 1.6 of 26300

Sun Jul 21 17:58:55 CEST 2013

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Makoto,

I will try to mine the email archives if necessary but as you will
recall, ODF 1.0 had several paragraphs of prose attempting to restate
the whitespace processing rules for XML.

I unsuccessfully contended even in that version that we simply say,
XML whitespace handling and be done with it.

The counter argument was that developers don't read the XML spec and
in any case we wanted to say there are exceptions for some white space
handling (paragraphs come to mind).

The paragraph exception (preserve white space) was intentional and I
think well founded, if and only if your goal is to allow paragraph
level processing (ignoring subelements and styles) to capture most of
the presentation of a text.

Not my argument but it is at least a coherent argument for the rule.

So yes, I think you are correct, it should have always said: White
space processing as per XML Spec, but it didn't.

Which is where we find ourselves today.

Hope you are having a great weekend!

Patrick

On 07/21/2013 03:16 AM, MURATA Makoto wrote:
> Dennis,
> 
> 2013/7/21 Dennis E. Hamilton <dennis.hamilton at acm.org>:
>> 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.
> 
> Regards, Makoto
> 
> 
>> 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: 
>> <https://tools.oasis-open.org/version-control/svn/oic/TestSuite/trunk/odf12/NameSpaceResilience/NameSpaceResilience-Results.htm>.
>>
>>
>> 
There are more details here:
>> <https://tools.oasis-open.org/version-control/svn/oic/TestSuite/trunk/odf12/NameSpaceResilience/>
>>
>> 
with a description of the files here:
>> <https://tools.oasis-open.org/version-control/svn/oic/TestSuite/trunk/odf12/NameSpaceResilience/NameSpaceResilience.txt>.
>>
>>
>>
>>
>> 
- -----Original Message-----
>> From: eb2mmrt at gmail.com [mailto:eb2mmrt at gmail.com] On Behalf Of
>> MURATA Makoto Sent: Saturday, July 20, 2013 08:47 PM To:
>> dennis.hamilton at acm.org 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
>> 
>> [ ... ]
>> 
> 
> 
> 

- -- 
Patrick Durusau
patrick at durusau.net
Technical Advisory Board, OASIS (TAB)
Former Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)

Another Word For It (blog): http://tm.durusau.net
Homepage: http://www.durusau.net
Twitter: patrickDurusau
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJR7AU3AAoJEAudyeI2QFGo9OgQAKYOb8KwrElygSoYMdTWfkaM
jrZEkt3U9oLVutCYMBvUOeNpjbxAlMq7CUB24VlLYfKzx/FRi0AUSCLe248VaUDl
RJjtjIDc9hiEOOaKn8eRpAW3JF9pg7FRFwbCR8WbfHuhAbCD2fuWfUBkQomc5+/D
y8k5W2xxIyYANyZO1k9VBh1jkynPYPigE7ByYhbpLZ9HFUtofzTvjQ0hAllOcEFV
GABx5CIct5HVbDQmKY1IcP94jznGCMFKl38ZltJEh0k0ZYVHthKqLDk1rAnfyJqw
DzdtH9Xknmn7T1IQuyGqf4SMWxDAl4f6dLSKWb9BJAuTEbjSG74zbnnyh+BgnDkO
GZRvEgcbkFeQRSNZKUUf3xP0OkOy4NZx8FYSewzosgZCwt1hoyC3P05QLDO8RBpE
tkb7+wowLmh4bTgxgRJVa6/yAqygVZJ/NnHpzu9hmPhX5EjiK5oBH5lRfajtNFuv
1AXDYPqSxcdol6dPWauAm/w7Pq51kCuhIWtiwLchfeSkVvsLyR1oDj2CxJJGTgPZ
muFsT4EjLxLMnSu8NjyEMViTmcIQA4+aZDpv0loUJ8vBFfwYe9AkVeO4uMY5syz3
5fjejnc+oKWjQ0m/SNEmUAxz/WquKQugy75tUstIXztFaxGxzQ3+SRLz4p7xnIAB
ow1RzOX90Xn/Ned4QCYU
=9rmm
-----END PGP SIGNATURE-----