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: Re: [office] structured fields


Just a brief note on MSO fields.

Fields in MSO are somehow different to what you refer to. MSO fields can start anywhere and can end anywhere.
Sample
<p>
<span>ABC</span>
<field-start field-code="text"/>
<span>DEF</span>
</p>
<p>
<span>GHI</span>
<field-end/>
</span>JKL</span>
</p>
Very close to the way change tracking is encoded in OpenDocument.

Best regards,

Florian


> -----Ursprüngliche Nachricht-----
> Von: Bruce D'Arcus <bruce.darcus@OpenDocument.us>
> Gesendet: 10.07.06 01:12:18
> An: OpenDocument <office@lists.oasis-open.org>
> Betreff: [office] 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 
> below).
> 
> 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"/>
>    </choice>
> 
> 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:citation>
>    <cite:citation-source>
>      <cite:biblioref cite:key="doe99a" cite:style="year">
>        <cite:detail cite:units="pages" cite:begin="23" cite:end="24"/>
>      </cite:biblioref>
>    </cite:citation-source>
>    <cite:citation-body>
>      <span class="citation">(1999: 23-24)</span>
>    </cite:citation-body>
> </cite:citation>
> 
> 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?
> 
> 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 
> 


_____________________________________________________________________
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071&distributionid=000000000071



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