OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: On "fields"


I want to thank Michael for the excellent post on "fields" and the 
various uses of that term in the ODF context. It has given me much to 
think about and I wanted to share some observations and comments on 

When I think about "fields" in ODF it is mostly from experience with 
using OpenOffice, KOffice and more recently Lotus Symphony. So consider 
the following with that caveat.

The most common characteristic of a "field" is that it involves some 
computation by the application in a particular context which results in 
content being inserted in the document.

For example, if I set the date "field" in a footer, then every time a 
new page is created, that computed content (unless I am uses a fixed 
date) is placed in the footer. Same is true for text that is 
automatically inserted in some particular location, say the header for 
right or left hand pages. The user specifies the text and its location 
but the actual placement is triggered by some event, in the case of page 
headers, by the creation of another page where the header should appear.

Needless to say that formatting styles can be associated with the 
content that is inserted as the result of the definition of a "field."

And the "content" consists of markup as well as user specified text or 
other material that appears on the markup.

So, to separate out some of the requirements from the prose:

1. Choice/Input of content by user

2. Placement/Location of that content in a document (actually in the 
markup as seen from the 'other' side)

3. Triggering event, such as occurrence of a location or occurrence of 
other content in a document

4. Choice of styles for the content chosen or input by the user

5. The resulting markup should, whenever possible be well-formed, to 
make it easier to process by standard XML tools (Yes, some users may 
describe what they want as paragraphs that 'span' other paragraphs but 
that isn't really necessary in any cases that I have seen. What they 
want is paragraph formatted content that may be distinguishable from the 
paragraphs surrounding the content, but that hardly requires 'spanning' 

6. Content and markup are limited only by the appropriate definition in 
ODF. (In other words, speaking of the general case, there is no 
limitation until we pronounce one. Such as saying that a date "field" 
contains only a date, for example. Not a limitation on a "field" 
generally but certainly a limitation on that particular one.)

If I had to pick one that distinguishes a "field" from anything else in 
an ODF document I would say that it is the triggering event that makes a 
"field" somehow different. There is nothing that prevents me from 
manually entering page numbers for example and styling them much as a 
page number "field" but I am likely to make a mistake and it really is 
more convenient to have the correct page number appear as I create new 
pages. Otherwise, all the things we can say about a "field" are largely 
the same ones we could say about any other content in an ODF document.

Does that seems like a useful continuation of Michael's explanation of 
"fields" in ODF?

Hope everyone is having a great weekend!


Patrick Durusau
Chair, V1 - US TAG to JTC 1/SC 34
Acting Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)
Co-Editor, OpenDocument Format (OASIS, ISO/IEC 26300)

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]