OASIS Open Document Format for Office Applications (OpenDocument) TC

Hi Eike,

On Fri, 2007-06-15 at 17:49 +0200, Eike Rathke wrote:
> Hi Kohei,
> 
> On Wednesday, 2007-06-13 14:58:08 -0400, Kohei Yoshida wrote:
> 
> >    
> > 
> > How should we interpret this?  Is the leading whitespace significant in
> > this case, or not?
> 
> It is, see ODF section 1.6 "White-Space Processing and EOL Handling".

Yes.  When the above input is given, technically we should parse it as

0xA 0x20 0x20 0x20 0x20 0x20 0x20 Jown Doe

But my point was that the producer of that input probably may not have
intended to include those 0xA and 0x20's.  This case may arise
especially when the XML input is hand-written or pre-processed by a XML
beautifier.

> 
> > There is also a line break right after the opening
> > element.  Should we take it, or not?
> 
> Again yes. There would also be a line break before the closing element.
> 
> > If we use an attribute for this, however, things are a little less
> > complicated, because (as I understand it) line breaks are not allowed in
> > an attribute, and if there is a leading and trailing whitespace in the
> > value, it is more explicit.  For instance, given the following:
> > 
> >    

On Friday 15 June 2007 18:45:56 Kohei Yoshida wrote:
> > It is, see ODF section 1.6 "White-Space Processing and EOL Handling".
>
> Yes.  When the above input is given, technically we should parse it as
>
> 0xA 0x20 0x20 0x20 0x20 0x20 0x20 Jown Doe
>
> But my point was that the producer of that input probably may not have
> intended to include those 0xA and 0x20's.  This case may arise
> especially when the XML input is hand-written or pre-processed by a XML
> beautifier.

It is a standard in XML that all text is preserved; all XML tools are 
fully aware of that rule and will do the right thing.
So, really this is problem :)

-- 
Thomas Zander

On Friday 15 June 2007 18:59:36 Thomas Zander wrote:
> It is a standard in XML that all text is preserved; all XML tools are
> fully aware of that rule and will do the right thing.
> So, really this is problem :)

not a problem, naturally...

-- 
Thomas Zander

Hi Kohei,

On Friday, 2007-06-15 12:45:56 -0400, Kohei Yoshida wrote:

> > I don't really oppose your attribute approach though, I just don't see
> > a real advantage.
> 
> The real advantage is less ambiguity in string value interpretation,



> and ease of copying one of the multi-string data into the existing
> table:value attribute for backward compatibility.

Ok, this special case may be seen as an advantage to the implementor.

> Other than that, I don't see any other differences one way or the other.
> But my vote is for using an attribute for ease of implementation.

I'm fine with that.

  Eike

-- 
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS