[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] sub chapter <office:dde-source> in chapter <text:section>lost in ODF 1.2 draft 7-13
Oliver, Oliver-Rainer Wittmann - Software Engineer - Sun Microsystems wrote: > Hi Patrick, > > sub chapter <office:dde:source> in chapter <text:section> is lost > between ODF 1.2 draft 7-11 and ODF 1.2 draft 7-12. > I also did not found its content any more in the rest of the ODF 1.2 > draft 7-13. > Any reason why this sub chapter including its content has been deleted? > The "content" or "information" was *not* deleted. See (in ODF 1.2 draft 7-12) section 4.4.1. From 7-11 the section you ask about: **** The |<office:dde-source> element represents DDE linking information for a linked section.| |Note:|| |Because a DDE linked section contains the XML rendition of the DDE link's content, this information only needs to be processed if updated data from the DDE link are desired. Ed. Note This should be true for <text:section-source> as well. So why say it for one and not the other? **** Note the editor's note. Then, in 7-12 (and following) also at 4.4.1 ***** Sections support two ways of linking to external content. If a section is linked to another document, the link can be through one of the following: * A resource identified by an XLink, represented by a |<text:section-source>| element * Dynamic Data Exchange (DDE), represented by a |<office:dde-source>| element The |<text:section-source>| or |<office:dde-source>| elements occur only in the alternative and then as the first child element of a |<text:section>| element. A section that links to external content contains a full representation of the data, so that processors need to understand the linking information only if they wish to update the contents of the section. ***** So while it is true that the subsection itself does not appear verbatim the same, the information that it was meant to convey is more usefully (at least in my view) reported to potential readers of the specification. Unless you wish to suggest that the semantics of the <office:dde-source> element, despite being defined once in the schema are different when the element occurs in sections versus tables? See 13.6.6 under common content for a fuller description of the element. I freely concede that the process of defining every element and attribute once makes proofing (for this round) more difficult and I work with several versions open at the same time, but in the long run knowing that if an element or attribute definition change must be made that while its impact must be traced out that we can make a change confident that is the only place where the change need be made, I think will help the TC as it continues to develop ODF. Imagine editing an XML schema where "combine" was implied so you don't know if you have found all the parts of a definition or not. Add to that the assumption that there are multiple ways to speak of the same element. And you may or may not know all of them. Just as you would want to avoid that for the schema, I want to avoid the same thing for the prose text. Hope you are having a great day! Patrick -- Patrick Durusau patrick@durusau.net Chair, V1 - US TAG to JTC 1/SC 34 Convener, JTC 1/SC 34/WG 3 (Topic Maps) Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300 Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]