[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
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]