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

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

Hi Bruce,

Bruce D'Arcus wrote:
> Oliver-Rainer Wittmann - Software Engineer - Sun Microsystems wrote:
> 
>> there are no more comments or questions coming in on this topic. Also, 
>> nobody else provided new Pros or Cons for the different variants.
>> Thus, I want to propose to restrict our further discussion on variants 
>> (4a)/(4b) and (2) as the next step on this topic. Any objections?
> 
> No objection.
> 
>> I also want to ask the TC members to state their opinions on variants 
>> (4a)/(4b) and (2) in order to come to a conclusion, for which variant, 
>> we should work out a concrete proposal.
>>
>> My personal opinion is that we should choose variant (4a)/(4b) or 
>> variant (2) to fulfill the made feature request - each of these 
>> variants would be Ok for OpenOffice.org.
> 
> I guess I lean towards 4a or b, since it's well-formed.
> 
> I do have a couple of questions though:
> 
> Michael presented this example:
> 
> <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'm a little confused by the 
> text:NEW-ELEMENT/text:p/text:NEW-ELEMENT-PREFIX path. Why is the 
> paragraph a child of the field, and the prefix a child of that paragraph?

This has three reasons: 1. From the structural perspective, the prefix 
is part of the paragraph. The user sees it as part of the paragraph, and 
if one asks for the content of the paragraph, one wants to get the 
content including the prefix, and not just the text the user enters. 2. 
If the prefix is not part of the paragraph, all implementations, have to 
implement a merging algorithm, even those applications, that only want 
to display a document and don't care about fields. This can be avoided 
if the prefix is part of the paragraph. In that case, only the start and 
end tags have to be ignored. That's, compared to merging, a trivial 
operation. 3. It saves us from specifying how to merge the prefix with 
the paragraph, which would not be trivial to specify, and, more 
important, not trivial to implement.


> 
> And am I right to understand the text:NEW-ELEMENT would appear within a 
> text:p element? Or would it stand alone; e.g.:
> 
> <text:p>...</text:p>
> <text:NEW-ELEMENT>...</text:NEW-ELEMENT>
> 
> ...?

It would be stand alone, that is, may occur where paragraphs can occur.
For input fields within paragraphs there would be the traditional text 
field, for which we probably would allow arbitrary paragraph content, 
but that does not support paragraph breaks.

> 
> I'm partly asking about the prefix and suffix elements because we were 
> suggesting something analogous as RDF properties for the 
> text:meta-field, and want to make sure we have some common understanding.

I have thought about this, too, but I'm not sure whether this is really 
the same. In the input field case, the prefix and suffix are those 
portions of the paragraph that the user does not enter. If the user for 
instance deletes the field, one would probably copy the prefix and 
suffix to the document as static content.

In the metadata field case, it is my understanding that the prefix and 
suffix are part of the generated text. That is, they are parameters for 
the (plug-in specific) algorithm that creates the label. If the metadata 
field is deleted, then the prefix and suffix will be deleted, too.

I therefore think that the two things are similar, but not the same.

> 
> And for Michael:
> 
>> (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.
> 
> Yes, while it has a certain elegance at the markup level, I was 
> wondering the use case for this. Please provide an example.

I don't have a specific example at hands. But if you have a paragraph 
where you want to have two places where the user can enter text, and not 
just text, but also paragraph breaks, then a prefix and suffix would not 
be sufficient. If the user can enter text only, you could still use the 
"old" text field. Is that clearer now?

Anyway, this was just a suggestion for the case we think we need that. 
If there is no use case for this, we can just forget about it.

Michael
> 
> Bruce
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in 
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php


-- 
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: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering