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: 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]