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

[Patrick Durusau <patrick@durusau.net>]

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.

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

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.

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.

Hope you are having a great day!

Patrick
>
> Best regards, Oliver.
>