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