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