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: structured fields

I raised this question on the metadata list, and would like to raise it 
here ...

Right now, ODF has a series of different kinds of field elements. They 
are collectively defined like so in section 6.1:

> Each field type is represented by a corresponding element type. A 
> field in a document is encoded as a single element of the appropriate 
> type. The content of the element is the textual representation of the 
> current field value as it would be displayed or printed. Therefore, 
> ignoring all field elements and displaying only the textual content of 
> the elements provides an approximate text-only version of the 
> document.
> The value of a field is usually stored in an attribute. It is 
> necessary to store the value so that the presentation of the field can 
> be recomputed if necessary, for example, if the user decides to change 
> the formatting style of the field. It is also necessary to store the 
> presentation style of the element content, to facilitate easy 
> processing of the XML document. For example, if complete processing of 
> a field is impossible or undesirable, the application can ignore the 
> field and use only the content in this situation. For string values, 
> if the value is identical to the presentation, the value attribute is 
> omitted to avoid duplicate storage of information.

So these are basically what we might call simple fields.

However, for some cateogries of use cases -- such as the citation one 
I'm interested in -- such simple fields are insufficient. For this 
reason, when Daniel Vogelheim and I wrote the new citation support 
scheduled for ODF 1.2, we basically created a new kind of field (more 

It is also for this reason, presumably, that MS also has a structured 
field element; what they call "structured document tags." Here is how 
they define them in section 16.3 of their OXML ECMA spec:

> The final type of customer-defined semantics which can be embedded in 
> a WordprocessingML document are structured document tags (SDTs).
> As shown above, smart tags and custom XML markup each provide a 
> facility for embedding customer-defined semantics into the document: 
> smart tags, via the ability to provide a basic namespace/name for a 
> run or set of runs within a documents; and custom XML markup, via the 
> ability to tag the document with XML elements and attributes specified 
> by any valid XML Schema file.
> However, each of these techniques, while they each provide a way to 
> add the desired semantic information, does not provide a way to affect 
> the presentation or interaction within the document. To bridge these 
> two worlds, structured document tags allow both the specification of 
> customer semantics as well as the ability to influence the 
> presentation of that data in the document.

So these are basically structured fields backed by custom XML content. 
The types choices from their schema are:

<choice minOccurs="0" maxOccurs="1">
   <element name="equation" type="CT_Empty"/>
   <element name="comboBox" type="CT_SdtComboBox"/>
   <element name="date" type="CT_SdtDate"/>
   <element name="docPartObj" type="CT_SdtDocPart"/>
   <element name="docPartList" type="CT_SdtDocPart"/>
   <element name="dropDownList" type="CT_SdtDropDownList"/>
   <element name="picture" type="CT_SdtPicture"/>
   <element name="richText" type="CT_Empty"/>
   <element name="text" type="CT_SdtText"/>
   <element name="citation" type="CT_Empty"/>
   <element name="group" type="CT_Empty"/>
   <element name="bibliography" type="CT_Empty"/>

Here's what I'm wondering:

What if we modified the already-approved citation proposal to be 
broader? E.g., if this is an example of the new citation field:

     <cite:biblioref cite:key="doe99a" cite:style="year">
       <cite:detail cite:units="pages" cite:begin="23" cite:end="24"/>
     <span class="citation">(1999: 23-24)</span>

It's occurred to me, in part in looking at how MS is implementing 
similar suppport (using SDTs), that this could (almost) all be generic:

cite:citation = text:structured-field[@type="citation"]
cite:citation-source = text:field-source
cite:citation-body = text:field-body
cite:biblioref = text:reference
cite:biblioref/@cite:key = text:reference/@dc:source (not sure ths 
attribute is right, but something like that; takes a uri to associate 
field with metadata)

... etc.

I partly raise this now because I'm wondering if people can imagine 
other kinds of metadata-backed structured fields as part of our use 
cases (maybe we already do?)?

We then can say all ODF apps must be able to display the structured 
field body, but leave it up to implementations whether they can process 
them. That way, for example, everybody can read and display citations 
without having to explicitly code for it.

Also, this would help interop with OXML.

Any opinions?


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