Re: [office] Some remarks on the "Fieldmarks" proposal from FlorianReuter

[Oliver-Rainer Wittmann - Software Engineer - Sun Microsystems<Oliver-Rainer.Wittmann@Sun.COM>]

Dear TC members,

Patrick Durusau wrote:
> Oliver,
> 
> Oliver-Rainer Wittmann - Software Engineer - Sun Microsystems wrote:
> <snip>
>> (2) It is stated in the proposal text that the "Fieldmarks" need to be
>> properly nested.
>> This is not assured by the current proposal. The reason for this is that
>> the content of the proposed element <field:fieldmark> is
>> paragraph-content and that the proposed elements <field:fieldmark-start>
>> and <field:fieldmark-end> belong to paragraph-content. Thus, a certain
>> <field:fieldmark> element could contain a <field:fieldmark-start> or
>> <field:fieldmark-end> element, but no <field:fieldmark-end> respectively
>> <field:fieldmark-start> element. Thus, overlapping of "Fieldmarks" is
>> possible.
>> In my honest opinion this needs to be fixed in the proposal.
>>
> I understand (I think) Florian's request that fieldmark's properly nest 
> but I don't understand why they should properly nest.

I think Florian's request to have "Fieldmarks" properly nested is caused 
by the use cases that he has in mind. That is only a guess - Florian 
should answer this question.

> 
> Particularly if it is possible that we want to use these as a generic 
> mechanism to replace the various similar mechanisms we have now, some of 
> which already allow overlapping by virtue of their identification of 
> their counter-parts, i.e., they don't have to rely upon their position 
> in the tree to identify the corresponding start/end element.

Yes, when we switch to such a generic mechanism I think we have to 
distinguish between "Fieldmark" types, which allow overlapping, and 
"Fieldmark" types, which have to be properly nested.

>> (3) On the one hand I like the generic approach which has been proposed,
>> but on the other hand I am missing the sematic of certain "Fieldmark"
>> types and its possible additional parameters. I think it is no good idea
>> to leave everything completely open to the application's implementation
>> regarding these "Fieldmarks". E.g., a certain "Fieldmark" type
>> implemented by ODF supporting application A can not be supported by any
>> other ODF supporting application.
>> What I would like to see is that the ODF specification should provide
>> the known use cases of "Fieldmarks" - e.g. the text input field and the
>> checkbox which Florian Reuter already had implemented in a patch
>> submitted to OpenOffice.org. Additionally the ODF specification should 
>> allow further unknown "Fieldmark" types in ODF documents, but it 
>> should be specified, how these unknown "Fieldmark" type are treated on 
>> import,
>> editing, export, etc. We should also encourage the ODF implementors to
>> submit their "Fieldmark" types to the ODF specification.
>>
> Yes,  I thought that was discussed when the potential to have a more 
> generic mechanism came up.

That is also my opinion that it was already discussed.

> 
> That is that a known set of such items would be described with a defined 
> set of semantics. Not simply leaving it up to the application as you say.

+1

> 
> However, I deeply suspect that even deprecating the similar mechanisms 
> would be something for the version of ODF past 1.2 to consider, even if 
> we allow the fieldmark mechanisms in 1.2.

+1

> 
> That may be overly cautious on my part so I would like to hear what 
> others have to suggest on the fashioning and use of a generic mechanism, 
> a move that I strongly support. There is no reason to have several very 
> similar mechanisms that could be replaced by one in ODF.

+1

Best regards, Oliver.

-- 
=======================================================================
Sun Microsystems GmbH    Oliver-Rainer Wittmann
Nagelsweg 55             Software Engineer - OpenOffice.org/StarOffice
20097 Hamburg
Germany                  Fax:   (+49 40) 23 646 550
http://www.sun.de        mailto:oliver-rainer.wittmann@sun.com
-----------------------------------------------------------------------
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

=======================================================================
Oliver-Rainer Wittmann (od) - OpenOffice.org Writer
OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS