|
[
Permalink
| « Hide
]
Patrick Durusau added a comment - 06/Jul/09 01:42 PM
Proposal filed.
Reject? The text in 15.20 (of ODF 1.1) is completely meaning less without some definition of what reference points and measure lines are.
!5>20 says that "the properties described in this section are specific to measure drawing objects" and then in 15.20.1 it immediately says that draw:line-distance specifies the distance from the reference points to the measure line. Which reference points? (What are the reference points of a circle? What are the reference points of a square?) What is a measure line?) Without a definition of these terms any two groups implementing this will end up with a different interpretation. Saying that "The nature of reference points and measure lines will vary according to the illustration in question..." is just a cop out. If they vary we must say how they vary. 7/13/09 ad-hoc similar to 1818
DISCUSSION REQUIRED
I agree with Andreas, I don't understand what it is we are rejecting. In conjunction with ALTERNATIVE A: 1. Report these as deferred to future work in the defect-report response. ALTERNATIVE B: 2. Alternative A supplemented by a decision whether or not we will put in a remedy for ODF 1.2 and then see how to correct across ODF 1.0/IS 26300/ODF 1.1. 3. Find a definitive source on the matter and see how to adapt it in a way that it abstracts for ODF in a way that is consistent with what any implementations actually provide already. ALTERNATIVE C: 4. Alternative A, and If there are no implementations, make explicitly implementation-defined in ODF 1.2, and bring in something understandable for ODF-next that deprecates the implementation-defined provisions.. Dennis/Andreas,
Please understand that I don't disagree that this particular section of ISO 26300 needs work, or that this section in ODF 1.2 can't be improved. However, having said that, defects are supposed to state with some detail the nature of the defect. So that I have some idea of what response would satisfy the concern. Simply saying "add diagrams" isn't enough for anyone to formulate a meaningful response. That may seem like a petty point to insist on but I am really reluctant to encourage "this section isn't understandable without using OpenOffice..." sort of comments. For example, if the comment had said: "It is implied by draw:placing ("The draw:placing attribute specifies whether the measure line is rendered below or above the edge defined by the two reference points.") that a measure line always has a horizontal orientation. For the values "above" and "below" to be meaningful. See also draw:measure-line, also implying a horizontal placement. However, the standard fails to explicitly state that all measure lines are in fact horizontal." That is a defect that I can analyze and answer. To put it another way, I really, really, dislike vague reports of defects. I won't name the national body but some are bad about "....here and elsewhere in the text." Well, if you know where "...elsewhere in the text." is it would be far more helpful to say. Sometimes (and I believe in this case) the amount of details of a defect reports reflect how well the specs is written. Since the spec fails to provide the most minimal definition of the terms used, a defect report cannot be any more specific.
Patrick, I agree with Andreas that there is no way that an external submitter (or maybe even most internal submitters) could specify a remedy here. It is often possible to recognize that something is not understandable without knowing what the intent was (i.e., not even the intent is discernable).
I don't believe it is appropriate to reject the defect report in this instance. We might well take Alternative C simply because we don't have the resources or the time to do better. The description of <draw:measure> has been reworked in ODF 1.2. See
1. It appears that 9.2.11 would have been helped immeasurably by reference to 15.20 and that could have helped in the resolution of N1078:27 (See Office-1818).
2. I think the defect claimed here is legitimate and could indeed be solved in the manner requested. This would seem to be purely expository and should not contradict implementations, unless there is a serious concern that implementations have interpreted the <draw:measure> element, the related attributes and properties in conflicting ways. 3. In either case, I believe that the resolution "Rejected, the correction of this defect would exceed the limits of OASIS errata and therefore it will be addressed in ODF 1.2. The behavior in question is implementation dependent for purposes of ISO 26300." is inappropriate. First, this is an Errata document for ODF 1.0 and the statement about IS 26300 is inappropriate. A corrigenda derived by transposition of this errata to IS 26300, but I don't think it belongs here. Secondly, if the "behavior in question" is implementation-dependent, we should say so. 4. It seems if we are going to identify the implementation dependency, it requires something like the following: Add at the end of the first paragraph of section 15.20 the following sentence: """ Interpretation and realization of measure properties is implementation dependent. """ There are overlappings to issue 1818. Similar as in 1818 Patrick and suggest to be consistent and not resolve a subset, but providing a complete answer in a future ODF version.
Still I am following Dennis suggestion to drop the subphrase "for purposes of ISO 26300" as the OASIS errata document refer to the OASIS standard. Errata 02 - ODF 1.2 Reconciliation
The discussion of Measure Properties is expanded as part of the ODF 1.2 Part 1 section 10.3.12 <draw:measure> text and also in terms of any changes to the descriptions of relevant attributes and graphic styles. These are complex adjustments and it seems inappropriate to continue to say that "The layout of the measure drawing objects is implementation-dependent." There may be other defects of the expanded description, but these don't seem to have anything to do with how Errata 02 dealt with the case of ODF 1.0 Measure Properties. |
|||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Applied
Major
ISO/IEC JTC 1/SC 34 N 1078 : DEFECT REPORT NUMBER JP2-29