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