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

On 22/09/06, Lars Oppermann <Lars.Oppermann@sun.com> wrote:

> There was discussion as to what this means for white-space at the
> paragraph beginning but that has been resolved by the TC.

I didn't keep the email, but IIRC that was the phrase referring out
the html?
Do you believe that to be specific?

> specification furthermore defines the test:s element to represent
> sequences of white-space.
OK. If it is retained.

> 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.

I'm using that for clarity. My basis is a user expectation.

> White-space in ODF context has no semantic meaning beyond that of a word
> delimiter.

Is that a personal view or a quote from the spec?

> Hence, I am opposed to requiring ODF implementations to honor
> it in any way beyond that.

OK, we disagree.

> 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.

You're the first one to mention xml:space. I hadn't.

> 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".

XML based file format? That's all I'm asking for.
A reflection of XML rec support in this file format.

 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.

My view. A high value aspect of ODF is that I can process the XML
for other purposes. I may generate it using an implementation,
I may edit it in an implementation, but the high value to an organisation
is the XML on disk.
  Clearly you see no value in that.

The semantic meaning is that attributed by the user, not the implementor.
We differ on this seemingly.


Dave Pawson

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