OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office message

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

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

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



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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]