[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] Please put this discussion
Hi Bruce, nah --- its a bigger scope this time than the nested-field discussion we had before. OOXML-like fields as well as bookmarks are used by developers to mark parts of the document. My proposal is trying to give them a "clean" way of doing this. So field-marks are fo bookmarks which are controlled by scripts. (Since OOXML-fields can be seen as special bookmarks they are also covered by bookmarks.) A lot of developers today are using ODF-bookmarks too to mark parts of a document. They would benefit from field-marks too. ~Florian >>> "Bruce D'Arcus" <bdarcus@gmail.com> 05/05/08 7:07 PM >>> On Mon, May 5, 2008 at 1:00 PM, Florian Reuter <freuter@novell.com> wrote: > A note about the relationship to e.g. metadata. The metadata mechanism is incompatible with the "marking" mechanism of OOXML which is based on "special bookmarks"/Word-liel "fields". So this field-mark element is clearly for interop/harmonization and should remove the pain of using ODF bookmarks to encode MS fields... Florian -- can you define what you mean by "incompatible"? I presume you're just (again) bringing up the issue of overlapping markup in fields? If that's the case, then does that mean text:meta-field and your proposed new field are completely orthogonal? Or might there (as I assume based on your description of a use case of extension-generated content) be some overlap such that we don't have two completely different kinds of fields for the same use kind of use case? As a simple example, in your proposal, the type of the field is indicated with a token. In text:meta-field the field can be typed using an rdf:type statement, where the value is in fact a URI. I thought OOXML uses a similar URI-based mechanism to type at least one type of field. Bruce
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]