Re: [office] discussion about a feature request regarding user inputfields

[Michael Brauer - Sun Germany - ham02 - Hamburg <Michael.Brauer@Sun.COM>]

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