OASIS Open Document Format for Office Applications (OpenDocument) TC

Dear TC members,

I think it is the best to restart the discussion about the feature 
request regarding user input fields in word processing application and 
its possible model in ODF.

I will describe from the perspective of the Sun OpenOffice.org Writer 
team, what this feature request is and what we are our thoughts about 
the possible alternatives to model this feature in ODF. These thoughts 
should be taken as a starting point for a constructive discussion in the 
TC to find a solution for ODF how to model this feature in ODF.
Hopefully, I will finish this description today afternoon (central 
european time).

Regards, Oliver.

Oliver-Rainer Wittmann - Software Engineer - Sun Microsystems wrote:

> I think it is the best to restart the discussion about the feature 
> request regarding user input fields in word processing application and 
> its possible model in ODF.

Yes :-)

> I will describe from the perspective of the Sun OpenOffice.org Writer 
> team, what this feature request is and what we are our thoughts about 
> the possible alternatives to model this feature in ODF. 

I suggest you *only* focus on the use cases for now and make sure we're 
all agreed on that before moving on.

Bruce

Dear TC members,

here is the promised description about the feature request regarding
user input fields in word processing applications from the Sun
OpenOffice.org Writer team perspective.

Current status in OpenOffice.org Writer:
In OOo Writer, we have an user input field - named "OOo input field" in
the following to avoid term/name clashes. This OOo input field can be
inserted into a paragraph and can be filled with arbitrary characters as
its content. The content of the OOo input field can not be formatted
individually - it gets the format attributes of its enclosing paragraph
and/or enclosing text spans. Thus, the user has the possibility to make
the complete content of the OOo input field "Bold" by creating a
corresponding text span, which encloses the OOo input field. The OOo
input field also has a description.
Such OOo input fields can be used to create something like a formular:

The OOo input fields can be used to perform some kind of processing -
e.g. jumping from OOo input field to OOo input field and ask the user to
fill it with the appropriate content.
Another use case are template documents, which contain fixed text and
OOo input fields. These OOo input fields mark the document position, at
which the user has to complete the document text. E.g., a template
letter of a insurance company used to communicate with its customers on
a certain insured event. Such a template document contains fixed text,
which shouldn't be changed, but has to be completed by the stuff about
the certain insured event.
The OOo input field is currently saved in the OpenDocument file format
as a text input field represented by element 

Oliver,

An excellent description of current capabilities of ODF and what is 
desired!

Thanks!

Patrick

Oliver-Rainer Wittmann - Software Engineer - Sun Microsystems wrote:
> Dear TC members,
>
> here is the promised description about the feature request regarding
> user input fields in word processing applications from the Sun
> OpenOffice.org Writer team perspective.
>
> Current status in OpenOffice.org Writer:
> In OOo Writer, we have an user input field - named "OOo input field" in
> the following to avoid term/name clashes. This OOo input field can be
> inserted into a paragraph and can be filled with arbitrary characters as
> its content. The content of the OOo input field can not be formatted
> individually - it gets the format attributes of its enclosing paragraph
> and/or enclosing text spans. Thus, the user has the possibility to make
> the complete content of the OOo input field "Bold" by creating a
> corresponding text span, which encloses the OOo input field. The OOo
> input field also has a description.
> Such OOo input fields can be used to create something like a formular:
> 
> The OOo input fields can be used to perform some kind of processing -
> e.g. jumping from OOo input field to OOo input field and ask the user to
> fill it with the appropriate content.
> Another use case are template documents, which contain fixed text and
> OOo input fields. These OOo input fields mark the document position, at
> which the user has to complete the document text. E.g., a template
> letter of a insurance company used to communicate with its customers on
> a certain insured event. Such a template document contains fixed text,
> which shouldn't be changed, but has to be completed by the stuff about
> the certain insured event.
> The OOo input field is currently saved in the OpenDocument file format
> as a text input field represented by element 

Oliver-Rainer Wittmann - Software Engineer - Sun Microsystems wrote:
> Dear TC members,
> 
> here is the promised description about the feature request regarding
> user input fields in word processing applications from the Sun
> OpenOffice.org Writer team perspective.

Thanks!

Comments/questions below.

> Current status in OpenOffice.org Writer:
> In OOo Writer, we have an user input field - named "OOo input field" in
> the following to avoid term/name clashes. This OOo input field can be
> inserted into a paragraph and can be filled with arbitrary characters as
> its content. The content of the OOo input field can not be formatted
> individually - it gets the format attributes of its enclosing paragraph
> and/or enclosing text spans. Thus, the user has the possibility to make
> the complete content of the OOo input field "Bold" by creating a
> corresponding text span, which encloses the OOo input field. 

OK, first, this limitation definitely seems unnecessary.

> The OOo input field also has a description.
> Such OOo input fields can be used to create something like a formular:
> 
> The OOo input fields can be used to perform some kind of processing -
> e.g. jumping from OOo input field to OOo input field and ask the user to
> fill it with the appropriate content.

In this case, the "field" is being used to enter form data.

First question: what is/should be the relationship between an 
ODF-specific "input field" and xforms?

> Another use case are template documents, which contain fixed text and
> OOo input fields. These OOo input fields mark the document position, at
> which the user has to complete the document text. E.g., a template
> letter of a insurance company used to communicate with its customers on
> a certain insured event. Such a template document contains fixed text,
> which shouldn't be changed, but has to be completed by the stuff about
> the certain insured event.

So to get more specific on the use case, you mean something like ...

The user starts a new document based on a template, and Writer prompts 
them for, say, the date and description of some fire or theft, and that 
text then gets inserted in the appropriate place in the document?

Bruce

Hi,

Bruce D'Arcus wrote:
> Oliver-Rainer Wittmann - Software Engineer - Sun Microsystems wrote:
>> Dear TC members,
>>
>> here is the promised description about the feature request regarding
>> user input fields in word processing applications from the Sun
>> OpenOffice.org Writer team perspective.
> 
> Thanks!
> 
> Comments/questions below.
> 
>> Current status in OpenOffice.org Writer:
>> In OOo Writer, we have an user input field - named "OOo input field" in
>> the following to avoid term/name clashes. This OOo input field can be
>> inserted into a paragraph and can be filled with arbitrary characters as
>> its content. The content of the OOo input field can not be formatted
>> individually - it gets the format attributes of its enclosing paragraph
>> and/or enclosing text spans. Thus, the user has the possibility to make
>> the complete content of the OOo input field "Bold" by creating a
>> corresponding text span, which encloses the OOo input field. 
> 
> OK, first, this limitation definitely seems unnecessary.
> 
>> The OOo input field also has a description.
>> Such OOo input fields can be used to create something like a formular:
>> 
>> The OOo input fields can be used to perform some kind of processing -
>> e.g. jumping from OOo input field to OOo input field and ask the user to
>> fill it with the appropriate content.
> 
> In this case, the "field" is being used to enter form data.
> 
> First question: what is/should be the relationship between an 
> ODF-specific "input field" and xforms?
> 
I didn't see any relationship between the ODF text input field and 
xForms regarding the described feature request.
Probably, a relationship can be built up, but it is not intented and not 
needed for the given feature request.

>> Another use case are template documents, which contain fixed text and
>> OOo input fields. These OOo input fields mark the document position, at
>> which the user has to complete the document text. E.g., a template
>> letter of a insurance company used to communicate with its customers on
>> a certain insured event. Such a template document contains fixed text,
>> which shouldn't be changed, but has to be completed by the stuff about
>> the certain insured event.
> 
> So to get more specific on the use case, you mean something like ...
> 
> The user starts a new document based on a template, and Writer prompts 
> them for, say, the date and description of some fire or theft, and that 
> text then gets inserted in the appropriate place in the document?
>

Yes, there is something like this in OOo Writer:
When you have opened a text document containing several OOo input 
fields, such a process can be started by Shift-Ctrl-F9. Then a dialog 
pops up, in which the user can enter the text for the first OOo input 
field. Afterwards, the user can switch to the next OOo input field, and 
so on.

Regards, Oliver.

So here's some thoughts ...

First, I think all fields should work similarly in the sense of being
able to contain formatted content within them, as well as potentially
multiple paragraphs, etc. I'd suggest the content of fields be 
well-formed XML (rather than using the start/end approach). I'm not sure 
how best to solve Oliver's concern, but maybe the span I suggested would 
work?

I had not actually dealt with text:input-field before. So the question
I'm left with is what -- if anything -- might be the distinction
between this field and the new text:meta-field?

It seems to me that text:input-field is intended to conform to broadly
similar use cases as the new inline metadata support. In this sense,
it might (at least optionally) be understood as a UI mechanism to allow 
for inline metadata input, where the object of the triple is a literal 
(either string, or XML literal).

If I'm right, then, we need to make sure the new metadata attributes
are allowed on the input field (and any other similar fields) for cases 
where someone wants to add additional semantics on top of that input 
content.

The intention behind text:meta-field, by contrast, is to link to
structured RDF data. So user inserts a reference to a patient, or a
customer, or concept, and this field encodes that, displaying some
representation of that resource, and perhaps allowing additional
functionality to be bound to it. In other words, the content of the 
field is generated from RDF/XML metadata.

Bruce

Bruce,

thank you very much for your thoughts and ideas. They are very 
interesting. However, I think for the moment we should concentrate on 
finding a solution for the described feature request, which is (from my 
understanding) limited to some kind of "user input field".

Please note that I have set the term "field" into "". I did do so by 
intention, because I think we should be careful with the use of the term 
"field".  The question what a "field" is has been raised already several 
times. So, I would like to share my thought on this with you: If you 
look at the ODF specification, then there are many "fields". Or more 
precisely, there are many elements that we call "fields", but that 
interestingly don't have a "field" in their element names. The only 
thing that these "fields" have in common is that they can contain some 
text content, and that this text content usually has not been entered by 
the user by placing the cursor somewhere into the text and just typing 
in the text, as it is the case for regular text. But beside that, the 
various "fields" have very different characteristics and purposes. Take 
for instance a "field" that displays a page number. This has little in 
common with the "user input field" we are discussing here. In 
particular, while I totally agree that an "input-field" may contain 
paragraph breaks, I have some doubts whether a page number ever will 
contain paragraph breaks. So I honestly have some doubts that it is 
required to apply the extension we may agree on for "user inputs fields" 
to all other elements that we call "fields". But maybe to some.

I furthermore would like to mention here that the set of elements that 
ODF calls "fields" is different than the set of functionality that OOo 
calls "fields" in its UI, and that this set again is different than the 
set of C++ classes that are called "fields" in the OOo implementation. 
This applies to OOo, but I believe also to other application. Which 
means, there seems to be no universal definition what a "field" is, 
which applies to all office file formats, office UIs and 
implementations. They all user their own definition.

Having that said: I believe the most important property of "fields" is 
not that they are "fields". Its the functionality or semantic that they 
add to a document. It is more or less an arbitrary decision what we call 
a "field" in ODF, and what we don't call a "field", and it is up to us 
to decide what we call a "field", and that we don't call a "field".

So, for the "user input field", I think we should in the first place 
check how we would best represent the required functionality. We should 
not imply any special semantics or requirements from the fact that we 
call this a "field". Florian has implemented this with the help of 
bookmarks. So instead of calling it a "user input field" we may also 
have called it a "user input bookmark". In both cases, it is just a name 
for a functionality, not more. If we know how to represent the 
functionality, we may check whether there are other "fields" (or ODF 
elements we don't call "fields") that need the same functionality, and 
we may then check whether we still want to call these things "fields".

I hope this helps in our discussions.

Best regards

Michael

BTW: I suggest that we continue the discussion about "meta-fields" in a 
separate thread on the metadata mailing list.


Bruce D'Arcus wrote:
> So here's some thoughts ...
> 
> First, I think all fields should work similarly in the sense of being
> able to contain formatted content within them, as well as potentially
> multiple paragraphs, etc. I'd suggest the content of fields be 
> well-formed XML (rather than using the start/end approach). I'm not sure 
> how best to solve Oliver's concern, but maybe the span I suggested would 
> work?
> 
> I had not actually dealt with text:input-field before. So the question
> I'm left with is what -- if anything -- might be the distinction
> between this field and the new text:meta-field?
> 
> It seems to me that text:input-field is intended to conform to broadly
> similar use cases as the new inline metadata support. In this sense,
> it might (at least optionally) be understood as a UI mechanism to allow 
> for inline metadata input, where the object of the triple is a literal 
> (either string, or XML literal).
> 
> If I'm right, then, we need to make sure the new metadata attributes
> are allowed on the input field (and any other similar fields) for cases 
> where someone wants to add additional semantics on top of that input 
> content.
> 
> The intention behind text:meta-field, by contrast, is to link to
> structured RDF data. So user inserts a reference to a patient, or a
> customer, or concept, and this field encodes that, displaying some
> representation of that resource, and perhaps allowing additional
> functionality to be bound to it. In other words, the content of the 
> field is generated from RDF/XML metadata.
> 
> Bruce
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in 
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php


-- 
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: Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering