[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] feature request for enhanced OOo input fields: somesuggestions for discussion
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?
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>
...?
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.
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.
Bruce
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]