[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Comments 144, 146, 149, 150, 168, 177, 271, 318, 319 and 320
Dear TC members, below are proposed resolutions for a set of public comments. For most of them I had an action item to propose a resolution. 144: http://lists.oasis-open.org/archives/office-comment/200709/msg00000.html Proposed resolution: ODF 1.0/1.1: The example seems to be understandable even with the spelling error. Therefore, a correction should be included into an errata only if requested. ODF 1.2: The example in question is not contained in the ODF 1.2 specification. 146: http://lists.oasis-open.org/archives/office-comment/200710/msg00001.html The suggested <optional> rather than <zeroOrMore> indeed seems to be more appropriate, because the schema then implements the restrictions regarding the content that are defined by the specification text. Proposed resolution (ODF 1.2 only): Adapt schema 149: http://lists.oasis-open.org/archives/office-comment/200712/msg00000.html The description for table:value-type indeed is incorrect. The attribute is only used with <table:null-type>, the only reasonable value is "date" (for other values where is no corresponding value-type attribute), and it does exist only to meet the value-type+value attribute pattern that we have for table cells and fields. Proposed Resolution (all versions): Change description as follows: The table:value-type attribute specifies the type a null date value. The only value of the table:value-type attribute is date. Change the schema (ODF 1.2 only) to allow only "date" as value. 150: http://lists.oasis-open.org/archives/office-comment/200712/msg00001.html Proposed resolution: ODF 1.0/1.1: "tableoffice:value-type" -> "office:value-type" ODF 1.2: Does not occur. 168: http://lists.oasis-open.org/archives/office-comment/200801/msg00031.html #1: Proposed resolution: ODF 1.0/1.1: The 2nd "The following conditions are valid for paragraph styles:" must read "The following conditions are valid for table cell styles:" ODF 1.2: The list of conditions must be re-adapted to what we had in ODF 1.1, with above correction. #2: Proposed resolution (all versions): The values "control", "default" and "table-page" have to be removed from the list of values. #3: Proposed resolution: ODF 1.0/1.1: The "Background" has to be removed from the list, but this seems not be as severe as to include it in an errata. ODF 1.2: Does not occur #4: Proposed resolution: ODF 1.0/1.1: The background must not be mentioned as example, but this seems not be as severe as to include it in an errata. ODF 1.2: Does not occur #5: That a <style:style> element may be a child of <style:master-page> appears to be a bug in the schema. Master pages may contain shapes, but their automatic styles are contained in the <office:automatic> styles element. Proposed resolution (ODF 1.2 only): Correct schema 177: http://lists.oasis-open.org/archives/office-comment/200802/msg00003.html #1: Proposed resolution: ODF 1.0/1.1: chart:splines -> chart:interpolation ODF 1.2: Does not occur #2: Proposed resolution: ODF 1.0/1.1: It hasn't been specified how the offset is interpreted. This means that this is implementation defined here. ODF 1.2: Change description to: The chart:pie-offset attribute specifies the offset of a segment from the center of a circle or ring chart_ as a percentage of the radius_. [..] 271: http://lists.oasis-open.org/archives/office-comment/200807/msg00097.html The text:global attribute is described in ODF 1.1 as: > There is a common use case for large documents to be edited in separate > entities, such that there is a 'global' document, containing several > linked constituent subdocuments. This can be implemented by using linked > text sections (see section 4.4). To facilitate an editing application > adapting the user interface to better support the notion of 'global' > document with constituent parts (as opposed to a document with arbitrary > linked content), the text:global flag can be used. If set to true, it > informs applications that linked sections in this document have part-of > semantics. The actual XML representation of the sections does not change. and in ODF 1.2 as: > The text:global attribute specifies that linked sections should be > treated as having part-of semantics to form a single larger document. > The actual XML representation of these elements does not change. While the text in ODF 1.2 does not define the term "part-of" semantic, I think the introduction text makes it clear what is meant. The text in ODF 1.2 indeed seems to be too short. Proposed resolution (ODF 1.2 only): Documents may be divided into separate entities, such that there is a 'global' document, containing several linked constituent subdocuments. The subdocuments are referenced from the global document as linked text sections (4.4.2). They may be edited individually, but also as part of the global document. The text:global attribute specifies whether a document is a global document (value true) or not (value false). Note: The text:global attribute does not change the semantics of a document, but editing application may adapt the user interface depending on the value of the attribute to better support the notion of 'global' documents (as opposed to documents with arbitrary linked content). 318/319/103: http://lists.oasis-open.org/archives/office-comment/200705/msg00028.html N0942#70 N1078#JP2-34 N1078#JP2-35 http://www.itscj.ipsj.or.jp/sc34/open/1078.htm This defect report refers to the following language in 17.5 of ODF 1.0 2nd edition/ODF 1.1: > A relative-path reference (as described in §6.5 of [RFC3987]) that > occurs in a file that is contained in a package has to be resolved > exactly as it would be resolved if the whole package gets unzipped into > a directory at its current location. The base IRI for resolving > relative-path references is the one that has to be used to retrieve the > (unzipped) file that contains the relative-path reference. > All other kinds of IRI references, namely the ones that start with a > protocol (like http:), an authority (i.e., //) or an absolute-path > (i.e., /) do not need any special processing. This especially means that > absolute-paths do not reference files inside the package, but within the > hierarchy the package is contained in, for instance the file system. IRI > references inside a package may leave the package, but once they have > left the package, they never can return into the package or another one. Proposed resolution (all versions): A relative-path reference (as defined in §4.2 of [RFC3986], except that it may contain the additional characters that are allowed in IRI references [RFC3987]) that occurs in a file that is contained in a package shall be resolved as it would be resolved if the whole package gets unzipped into a directory at its current location. The base IRI for resolving relative-path references shall be the one that has to be used to retrieve the (unzipped) file that contains the relative-path reference. Note 1: Every IRI reference that is not a relative-path reference does not need any special processing. IRI references inside a package may address anything addressable by an IRI that is outside of a package or within the same package. Whether files within a package may be addressed by IRI references that are not contained in the package itself depends on the available IRI schemes and may be specific to the capabilities of a server or a file system which is references by the IRI or which resolves it. Note 2: Files contained in the META-INF directory of a package are considered to be part of the OpenDocument package file itself. Different rules regarding the resolution of relative-path references may apply to these files. Please note that this proposal is based on the discussion we had with Murata Makoto regarding these comments, as well on the discussion we had in the TC when preparing the ODF 1.0 errata. Please note further that I have turned the 2nd paragraph entirely into a note and have reworded it once again. The intention behind this 2nd paragraph never was to alter the behavior of absolute IRIs nor was it to forbid referencing files contained in packages from outside the package, if there is an appropriate scheme for this. The intention behind this 2nd paragraph was only that one should not expect that an URI like http://docs.oasis-open.org/office/v1.1/OpenDocument-v1.1.odt/content.xml (where http://docs.oasis-open.org/office/v1.1/OpenDocument-v1.1.odt is a valid reference to an ODF file) could be resolved. The current wording should make this more clear. 320: N1078#JP2-36 http://www.itscj.ipsj.or.jp/sc34/open/1078.htm Resolution: ODF 1.0/1.1: "chart:axis-interval-major" should read "chart:interval-major" and "chart:axis-interval-minor" should read "chart:interval-minor-divisor". ODF 1.2: Already corrected. Best regards Michael -- Michael Brauer, Technical Architect Software Engineering StarOffice/OpenOffice.org Sun Microsystems GmbH Nagelsweg 55 D-20097 Hamburg, Germany michael.brauer@sun.com http://sun.com/staroffice +49 40 23646 500 http://blogs.sun.com/GullFOSS Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer Vorsitzender des Aufsichtsrates: Martin Haering
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]