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

[Bruce D'Arcus <bdarcus@gmail.com>]

Michael Brauer wrote:

> Bruce D'Arcus wrote:

...

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

OK.

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

That makes sense.

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

The prefix and suffix are indeed part of the generated text, but those 
properties themselves would typically be user-supplied.

Bruce