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 <> 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 <> Sun Microsystems
Software Engineer Nagelsweg 55
Phone: +49 40 23646 959 20097 Hamburg, Germany
Fax: +49 40 23646 550 http://www.sun.com/staroffice
