[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] table:filter-condition extension proposal
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: > > > <filter-set-item> > > John Doe > > </filter-set-item> > > > > 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: > > > > <filter-set-item table:value=" John Doe"/> > > > > We can easily see that the leading whitespace there is significant, and > > evaluate it as such. > > In an element you'd easily see that as well. In general I agree with > voices saying that usually elements are preferable over attributes as > soon as the content looks like data ... I see it differently. In my view, we should default to using an attribute unless there is a clear advantage of using a text node. And I don't see a clear advantage of using a text node over attribute in this case, rather than to make the file format look pretty. > additionally we'd just introduce > an element to be able to assign one attribute with content, so why not > just use the element for the content instead? Because it would introduce some ambiguity in interpretation of the given data. Using an attribute here would make it less ambiguous. On top of that, as I stated in my proposal, for backward compatibility the producer should put the first item in the string set to the table:text attribute of the table:filter-condition element. If we use a text node for the multi-string set, then we would need to go through an additional data translation before copying it to the table:value attribute. If we use an attribute, on the other hand, we could simply copy the attribute value without requiring the conversion. To me, that's a real advantage. > > 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. 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. Kohei -- Kohei Yoshida - OpenOffice.org Engineer - Novell, Inc. <kyoshida@novell.com>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]