Re: [office] table:filter-condition extension proposal

[Kohei Yoshida <kyoshida@novell.com>]

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>