Re: [office] white-space processing proposal

[Lars Oppermann <Lars.Oppermann@Sun.COM>]

Dave,

The ODF specification is quite clear about the meaning of white space in 
text content. in 5.1.1, it is stated that they are to be collapsed. 
There was discussion as to what this means for white-space at the 
paragraph beginning but that has been resolved by the TC. The 
specification furthermore defines the test:s element to represent 
sequences of white-space.

If I understand you correctly, you are trying to make a case, that 
collapsing white space in the visual representation is nice and fine, 
but that there should be a requirement for implementors to retain any 
whitespace in the physical representation. You base this requirement on 
the definition of an XML processor in the W3C XML 1.1 recommendation.

White-space in ODF context has no semantic meaning beyond that of a word 
delimiter. Hence, I am opposed to requiring ODF implementations to honor 
it in any way beyond that.

You are mentioning xml:space. XML 1.1, 2.10 states that "A special 
attribute named xml:space may be attached to an element to signal an 
intention that in that element, white space should be preserved by 
applications". Please note the use of MAY and SHOULD here. Hence, there 
is no requirement for an XML application (or schema) to declare 
xml:space or use it.

I would like to draw a clear line here between an XML editor and an ODF 
editor. I am opposed to requiring that an ODF editor is an XML editor 
too. The OpenDocument Charter [1] states "The purpose of this TC is to 
create an open, XML-based file format specification for office 
applications". I don't see, where making the physical representation in 
the XML part of the specification has any merit for office applications, 
when that physical representation has no semantic meaning whatsoever. If 
there is such a use-case, I'd like to hear about it.

Bests,
Lars

Dave Pawson wrote:
> On 21/09/06, Peter Korn <Peter.Korn@sun.com> wrote:
> 
> 
>> I wonder if we can separate this into multiple issues, and tackle them
>> individually, and perhaps at least come to agreement on some (if not
>> all) of them.
>>
>>  1. White space should be preserved in ODF XML
>>  2. All ODF readers/writers should have the same understanding of white
>> space in ODF XML
>>  3. ODF XML should follow general XML rules
> 
> Amend 2 to read
> All ODF readers/writers should have the same understanding of white
> space processing in ODF XML
> and I'd agree.
> 
> 
>> It may well be that:
>>
>>   <text:p>  this  is  the   first    fragment</text:p>
>>
>> is a construction that no current ODF application/tool creates.
>> Certainly SO/OOo won't do this.  It'll instead do something like:
>>
>> <text:p><text:s text:c="*2*" />this <text:s />is <text:s />the <text:s
>> text:c="*2*" />first <text:s text:c="*3*" />fragment</text:p>
>>
>> So, if this behavior is clearly defined in the ODF spec, then we address
>> #1 and #2 above, right?
> 
> If you agree that writing 5 spaces, then having it translated into an 
> element
> is 'preserving spaces'.
> I wonder how many times it is more wasteful of file size?
> 
> 
> Michael, I believe you'd disagree with 1, is that true?
> 
> That only leaves #3.
>>
>> Dave - is it not possible in XML to define the SO/OOo behavior as valid?
> 
> Validity doesn't come into it.
> Conformant to XML 1.0 (or 1.1) is a precise statement.
> Michael defines ODF implementations as XML applications which are a layer
> above the xml 1.1 definition.
> 
> [Definition: A software module called an XML processor is used to read
> XML documents and provide access to their content and structure.]
> 
> [Definition: It is assumed that an XML processor is doing its work on
> behalf of another module, called the application.]
> 
> This  separates it from the requirements of an XML processor. I don't
> believe users expect that.
> 
> 1. I don't think ws processing is clearly specified in 1.1, e.g.
> the phrasing casting out to html browser implementations as an example
> is imprecise.
> Michael appears to want to retain the status quo, with implementation 
> dependence
> due to lack of precision. I'd like the ODF spec to be precise.
> My personal position is that I believe ODF should require ws processing 
> as per
> XML processors. My example proof might be,
> Edit a writer document. Insert and remove a space. Write to disk.
> Apart from metadata, the XML instance on disk should be identical to 
> that read.
> That demonstrates white space preservation.
> 
> regards
> 


-- 
Lars Oppermann <lars.oppermann@sun.com>               Sun Microsystems
Software Engineer                                         Nagelsweg 55
Phone: +49 40 23646 959                         20097 Hamburg, Germany
Fax:   +49 40 23646 550                  http://www.sun.com/staroffice