View source for Writer/Textfields/Minutes-2010-01-15

{{Writer Project}}
__TOC__
== IRC protocol ==
<tt>
--- Log opened Fri Jan 15 14:03:49 2010

14:03 <@b_michaelsen> .

15:05 < thorsten> heh

15:05 < thorsten> sorry,

15:05 < thorsten> in now.

15:06 <@b_michaelsen> k

15:09 -!- cbosdonnat [n=cbosdonn@ALyon-257-1-152-243.w81-251.abo.wanadoo.fr] has joined #sw.openoffice.org

15:09 <@b_michaelsen> thorsten asks about the goal for the meeting today ...

15:10 <@b_michaelsen> cws cbosdo02 is on the way to qa

15:11 <@b_michaelsen> od clarifies the reason for the call to communicate directly and prevent misunderstandings in email

15:12 <@b_michaelsen> s/to/is to/

15:15 <@b_michaelsen> OOo implementation is pretty much agreed upon bz all parties (roundtripping docs-files etc.), but ODF is still open for discussion because of the pros and cons

15:17 <@b_michaelsen> od gives an overview of previous work about standardization of fieldmarks in ODF

15:20 <@b_michaelsen> thorsten, basic stuff like listbox, checkbox etc. need to be completly speced, but wonders about other fieldmarks/extensibility. thorsten proposes those to be implementable by extension and still keep vaild ODF

15:22 <@b_michaelsen> thorsten "unsupported fieldmarks should be displayed and roundtripped by implementations even if they otherwise unsupported"

15:24 <@b_michaelsen> od: "too much freedom for extensibility will harm interop"

15:25 <@b_michaelsen> od: "we need to define what a fieldmark really is"

15:27 <@b_michaelsen> thorsten: "what are the drawbacks of extensibility?"

15:27 <@b_michaelsen> cedric: "interop"

15:32 <@b_michaelsen> thorsten: "allowing extensible fieldmarks allow at least fallback implementations in all implemenations (so this allows basic interop between all impls)"

15:33 <@b_michaelsen> thorsten: "interop still has a long way to go"

15:36 <@b_michaelsen> thorsten: "standardization of a simple set of features makes interop easier than specing out the cornercases that are raely used"

15:36 <@b_michaelsen> a/raely/rarely/

15:53 <@b_michaelsen> using fieldamrks as a container in ODF seems to be a good middle way between the two extremes proposed ...

15:56 <@b_michaelsen> od brings up nesting of fieldmarks

15:59 <@b_michaelsen> wrapup: container approach seems promising.

16:00 <@b_michaelsen> od "volunteered" to write down a proposal for the container apporach.

16:00 <@b_michaelsen> homework fo everyone: define "fieldmark"

16:01 <@b_michaelsen> closing time_

16:02 <@b_michaelsen> ?

16:07 <@b_michaelsen> od asked about reading/migration of existing go-oo docuuments containing fieldmarks.

16:08 <@b_michaelsen> call closed. ;)

16:08 < thorsten> then have fun hacking & bye!

16:08 -!- thorsten [n=thorsten@ooo/opensuse.member.netsroth] has left #sw.openoffice.org []

</tt>

== preparation for discussion about “fieldmark ODF” (by od) ==
=== agenda of discussion ===
# Collect each ones requirements for the "fieldmark ODF".
# Collect each ones Pros and Cons of the "strict generic" approach.
# Collect each ones Pros and Cons of the "strict typed" approach.
# Find a possible "fieldmark ODF" - ideally would be a solution which fulfills the requirements, brings together all the Pros and eliminates the Cons.

==== ad Collect each ones requirements for the "fieldmark ODF" ====

===== OD's requirement =====

'''R-OD-1:'''

Each “fieldmark type” needs to be specified in the ODF specification. Such a specification shall contain:
* The semantic of this “fieldmark type”
* The features of this “fieldmark type”
* mandatory and optional ODF elements and ODF attributes.
* allowed values for the ODF attributes.

Thus, the insertion of an unspecified “fieldmark type” using the generic approach's “language” into an ODF document would cause that this ODF document will no longer be ODF-conform.

This requirement allows each ODF supporting application to implement each “fieldmark type” in the same way as specified.

===== ad Collect each ones Pros and Cons of the "strict generic" approach. =====

'''Generic-Pro-OD-1:'''

It is a general framework.
# The introduction of new “fieldmark types” is highly supported.
# More or less one generic implementation is needed to include support of “fieldmarks” in ODF supporting applications.
# “Round-trip” of “fieldmarks” is easy to implement, even if the intrinsic “fieldmark types” are not implemented in the ODF supporting application, because only one generic implementation is needed.

'''Generic-Pro-OD-2:'''

Possible replacement for existing ODF concepts (fields, controls, …).

'''Generic-Con-OD-1:'''

It is not typed. A more complex implementation to validate the ODF of a certain “fieldmark type” is needed, because the constrains and restrictions have to be tested outside the XML scope.
This Con is weaken Generic-Pro-OD-1 – (b).
This Con should not be neglected in the area of the implementation of ODF validators

'''Generic-Con-OD-2:'''

No reuse of existing ODF concepts. This is the other side of the coin of Generic-Pro-OD-2

'''Generic-Con-OD-3:'''

The modeling of controls and forms as “fieldmarks” sounds strange.
This Con is more or less caused by the reason that we have not formulated the semantic/idea of a “fieldmark” yet. Thus, such a specification is much appreciated when a generic approach is followed. May be even the term “fieldmark” needs to be replaced.

'''Generic-Con-OD-4:'''

The generic approach is too feature-rich for the “fieldmark types” we have currently in our focus - “Form text”, “Check box” and “List box”. This might be a problem, when we bring this approach into the ODF TC and certain features are not used by the specified “fieldmark types”.

===== ad Collect each ones Pros and Cons of the "strict typed" approach. =====

'''Typed-Pro-OD-1:'''

It is typed. Each “fieldmark type” contains the stuff which it needs – not more, not less. Validation can be done in the XML scope.

'''Typed-Pro-OD-2:'''

Reuse respectively enhancement of existing ODF concepts is obvious.
OD's collected Cons

'''Typed-Con-OD-1:'''

Introduction of new “fieldmark types” is not supported.

'''Typed-Con-OD-2:'''

This approach is not usable for our OOo requirement to “round-trip” more or less every Microsoft Word “field” in ODF.