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] white-space processing proposal

Dave Pawson wrote:
> On 22/09/06, Lars Oppermann <Lars.Oppermann@sun.com> wrote:
>> It was specific enough for me. If you have a proposal on how to further
>> clarify it, I'd be happy to see that.
> I read waffle, not specifics.
> Am I that picky?

Again, if it can be improved, I'd be happy to see suggestions.

>> Literal
>> white-space in the XML is either a word delimiter, syntactic sugar or
>> both.
> Why are you unwilling to see it as content?

The reasoning behind not using literal whitespace for content, was to be
able to use it to format the Mark-Up. That is why we came up with the 
special handling of encoding multiple consecutive white-spaces in markup 
(which is in imho far better than &nbsp;&nbsp;... since that has yet 
another semantic)

>> Please provide some
>> explanation as to what the benefit of making the literal white space in
>> the XML representation is.
> No different from the xml rec itself.
> It is shy of deciding on ws semantics, why are you so bold?

The XML rec provides a framework for representing abstract content in a 
standardized way. I do not see any mentioned in that document as to 
requiring any specific interpretation of white space by applications. In 
other words, we are free to specify any interpretation of white-space 
that we see fit. The ODF spec states that consecutive occurrences of 
white-space in ODF are represented by <text:s> in the XML. Makes sense 
to me.

ODF applications should handle whitespace in a compatible way. In that 
light, the current solution is very practical. It allows applications 
(and users) to format the XML as they see fit and it allows applications 
to preserve the whitespace in places where no modification is made to 
the document.

You want literal white space to be preserved, and you are very well 
entitled to that view. However, I am still not seeing the point in 
requiring this from all implementations.

I don't mind that we are in disagreement here and I find it a worthwhile 
topic to debate. If you wish to drop the subject I shall live with it :)

Have a good week-end,

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