[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 all, Below is my personal opinion on the proposals. I'm replying to Bruce's mail, because he made some good points. To summarize my opinion: For a text input field I think (2) is a good choice, but (4a) and (4b) would also work for me. For a metadata field, (2) isn't a good choice, but only a solution similar to (4a)/(4b). Details are below. Bruce D'Arcus wrote: > Oliver-Rainer Wittmann - Software Engineer - Sun Microsystems wrote: > >> I've got the action item to follow up this issue on the mailing list. >> Thus, I want again ask for preferences or objections for the variants. > > My main points were: > > a) wanted some clarification of (different) generic fields (to see how > the new metadata field fits in, or not, and to in general clarify field > semantics) My view on this is that the user-input field is somehow special. Most elements that we call fields in ODF display some text based on certain information provided with the field. The user input field we are discussing here seems to be different. My understanding is that it is more like a bookmark at which the cursor may be located, and where the user may enter arbitrary content. So, I agree that it is very reasonable to see how the metadata field fits into the concept of other ODF fields. But because the text-input field itself is so special, I think most if not all other fields are more suitable for a comparison or analysis than the user input field. One of the difficulties we face with the user input field is that it may start within some paragraph, may end within some other, and allows arbitrary content. If this a requirement that exists for the metadata field? Or do we assume that it either contains full paragraphs (and then appears at the the same level as paragraphs) or only paragraph content (where it appears within the paragraph)? If we think that metadata fields shall start within a paragraph and may end within another, then it is reasonable to align them with the user input field. If this is not the case, then I could imagine that we use a different variants for the user input field than for the metadata field, namely (2) for the text input field, and something similar to (4a) or (4b) for the metadata field. My assumption is that meta data fields do not have the requirement to start or end in the middle of paragraphs. Simply because this would mean that the content of the metadata field would be a mixture of paragraph fragments and paragraphs, and I cannot imagine a use case where this is a reasonable content model for a metadata field. I can however imagine that it is reasonable to allow full paragraphs as content of metadata fields. But this again does not require that metadata fields may start or end within paragraphs. > > b) to express a general preference to prefer well-formedness to ease XML > processing (for example, XSLT) I agree to this, but think we have to take into account what the task is we want to solve using XSLT. This may be extracting the field content, but also extracting paragraph content, for instance to display or read the document. The original solution (4) for instance does make it very simple to extract the field content, but extremely difficult to get the content of a paragraph. So, the question is how often will it happen that someone requests the content of a user-input field using XSLT? Given the nature of the text input field, I guess that this does not happens often, in particular not if we compare this to the number of times a paragraph is displayed. The processing of documents for the purpose of displaying them is a little bit more difficult in solution (4a) and (4b) than in solution (2) actually. That's why I think (2) may be a good solution for a text input field. For a metadata field, the situation is different. I think it will happen more frequently that the content of a metadata field is processed. That's why I think (4a/b) is the better solution here. > > c) that I thought Florian's work on OOo was cool that I'd love to see it > help towards implementation of the new metadata field First of all, the question whether the OOo project (or any other project) may reuse an existing implementation should not influence our decision what a good representation of a feature in OOo is. The question is more whether implementations for one field could be reused for another in general, and here again the question is how much the two fields actually have in common. If they don't have much in common, then it may actually be easier to require two simple implementations, than a single but more complex one. Anyway, what OOo and other applications save to ODF is not their internal model, and I see nor reason why a metadata field could not reuse the implementation of a user-input field even if the representation on ODF is entirely different. > > I already indicated my general preference on the list (I think it was > for 4b IIRC). As for metadata field I'm in favor of 4a or 4b, too, though I do not know whether we really need the prefix and suffix here, which in the case of the user-input field are not considered part of the field content. I know that it has been discussed to have a prefix and suffix for the metadata field, too, but my understanding is that they there are considered to be part of the field content. So, though we both call prefix and suffix, we are in my opinion talking of two different things. If we can omit the prefix and suffix (as defined for the user-input fields), then solution (4a) or (4b) would get significant simpler, and not more difficult than (2) actually. But it also would not meet the requirements for text input fields any longer. That's why I think this would be a good option for the metadata field. As for the user-input field, I have a slight preference for (2), because it is very lightweight, and more important, is close to how the user sees it. But I have to admit that it is a slight preference only. That's why I say (4a) or (4b) would work for me, too. Best regards Michael -- 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]