[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] Some remarks on the "Fieldmarks" proposal from FlorianReuter
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]