Re: [office] feature request for enhanced OOo input fields: somesuggestions for discussion

[Michael Brauer <Michael.Brauer@Sun.COM>]

Dear TC members,

Oliver-Rainer Wittmann - Software Engineer - Sun Microsystems wrote:
> Dear TC members,
> 
> (4) usage of new element <text:NEW-ELEMENT> with the following features:
> - occurs where usual text-content can occur such as paragraphs, 
> headings, tables, lists, etc.
> - its content is text-content
> - optional content <text:NEW-ELEMENT-PREFIX>, which contains usual 
> paragraph content. If the first content of <text:NEW-ELEMENT> is a 
> paragraph, the content of <text:NEW-ELEMENT-PREFIX> is merged into this 
> paragraph at the beginning.
> - optional content <text:NEW-ELEMENT-SUFFIX>, which contains usual 
> paragraph content. If the last content of <text:NEW-ELEMENT> is a 
> paragraph, the content of <text:NEW-ELEMENT-SUFFUX> is merged into this 
> paragraph at the end.
> <text:NEW-ELEMENT>
>   <text:NEW-ELEMENT-PREFIX>
>     Special interests:
>   </text:NEW-ELEMENT-PREFIX>
>   <text:p>
>     <text:span text:style-name="BoldTextStyle>hobbies:</text:span>
>   </text:p>
>   <text:list>
>     <text:list-item>
>       <text:p>german soccer league</text:p>
>     </text:list-item>
>     ...
>   </text:list>
>   <text:p><bold>programming languages:</bold></paragraph>
>     <text:span text:style-name="BoldTextStyle>prog.lang:</text:span>
>   </text:p>
>   <table:table>
>   ...
>   </table:table>
>   <text:p><bold>programming languages:</bold></paragraph>
>     <text:span text:style-name="BoldTextStyle>others:</text:span>
>   </text:p>
>   ...
>   <text:list>
>     ...
>     <text:list-item>
>       <text:p>OpenDocument</text:p>
>     </text:list-item>
>   </text:list>
> </text:NEW-ELEMENT>
> <text:NEW-ELEMENT> would represent an "enhanced OOo input field,

This proposal has the advantage that the content inserted by the user 
into the input field is well formed and is not based on nested 
paragraphs, but it still has the problem that an application that just 
wants to view or read the document requires some extra processing, 
because the <text:NEW-ELEMENT-PREFIX> and <text:NEW-ELEMENT-SUFFIX> has 
to be merged into the paragraphs. I therefore would like to suggest a 
slightly modified solution, that does not have this problem. I call it 
(4a), to emphasize that it is a variant of (4).

(4a) is like (4), except that the optional <text:NEW-ELEMENT-PREFIX> 
does not appear in front of the first paragraph element, but must be the 
first child element of the first paragraph element. The optional 
<text:NEW-ELEMENT-SUFFIX> must be the last child element of the last 
paragraph. Above example would look like this:

<text:NEW-ELEMENT>
   <text:p>
   *<text:NEW-ELEMENT-PREFIX>*
     *Special interests:*
   *</text:NEW-ELEMENT-PREFIX>*
     <text:span text:style-name="BoldTextStyle>hobbies:</text:span>
   </text:p>
   <text:list>
     <text:list-item>
       <text:p>german soccer league</text:p>
     </text:list-item>
     ...
   </text:list>
   <text:p><bold>programming languages:</bold></paragraph>
     <text:span text:style-name="BoldTextStyle>prog.lang:</text:span>
   </text:p>
   <table:table>
   ...
   </table:table>
   <text:p><bold>programming languages:</bold></paragraph>
     <text:span text:style-name="BoldTextStyle>others:</text:span>
   </text:p>
   ...
   <text:list>
     ...
     <text:list-item>
       <text:p>OpenDocument</text:p>
     </text:list-item>
   </text:list>
</text:NEW-ELEMENT>

I've marked the changes by * characters/bold.

Application that view or read document can just ignore the new elements 
and process only their content, just as it is the case for all other 
fields today. Applications that want to get the user-inserted content 
can take the content of the field, and just remove the prefix and 
suffix, which is a trivial operation. The only disadvantage compared to 
(4) is that we cannot express in the schema that the prefix and suffix 
element must be the first or last elements of the first/last paragraph. 
Compared to the advantage that viewer/reader applications are saved from 
merging, this seems to be a minor disadvantage to me.

I'm not sure if it is required, but we may further extend solution  (4a) 
to a solution (4b), that provides more flexibility, and does not have 
this issue.

(4b) is like (4a), except that there is a single 
<text:NEW-ELEMENT-LABEL> instead of <text:NEW-ELEMENT-PREFIX> and 
<text:NEW-ELEMENT-SUFFIX>. This element may appear anywhere within the 
content. What we win by this is that a input field may have multiple 
areas, where text input is possible, mixed with areas that have 
non-editable content. We furthermore would not have to describe where 
the elements may appear, because they can appear anywhere. However, I'm 
not sure if we need this flexibility. If so, I may provide an example 
this may look like.

Best regards

Michael




-- 
Michael Brauer, Technical Architect Software Engineering
StarOffice/OpenOffice.org
Sun Microsystems GmbH             Nagelsweg 55
D-20097 Hamburg, Germany          michael.brauer@sun.com
http://sun.com/staroffice         +49 40 23646 500
http://blogs.sun.com/GullFOSS

Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1,
        D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering