|
[
Permalink
| « Hide
]
Patrick Durusau added a comment - 06/Jul/09 01:15 PM
Even in the current text this is still confused. Detective operations are spoken of as hiding/visible cells results and yet there is also a notion those operations highlighting cells. Needs work.
Patrick, we had some discussion via EMail, I think this issue is resolved and a resolution can be applied.
Please assign back to me if this isn't the case and you have further questions. There is no resolution provided in this JIRA issue and the Description Line "SOLUTION PROPOSED BY THE SUBMITTER" makes no sense - the defect report has no solution proposal.
This defect item covers a substantial amount of text, and the proposed repair is extensive. I think the repair to section 8.4.3 Detective might be improved by simplifying even further: """ The <table:detective> element determines how relationships between the current cell and other cells are to be revealed in presentation of the table. """ It is possible to go farther, but that seems unnecessary for the errata. E.g., """ Note: <table:detective> elements are useful for presenting the dependencies among cells on which calculated results and propogated errors are based. """ The substantial changes made to 8.4.4 might benefit from similar simplification. I suppose, after being clear how the element is interpreted we will then end up saying that the actual behavior that results is definitely implementation-dependent. I note that the defect report includes section 8.4.5 in the issue posed by the defect item.
Section 8.4.5 is not addressed in the proposed resolution in ODF 1.0 Errata CD04. For 8.4.4, the description of the table:name attribute in the table:operation element is changed. This is a great improvement that includes elimination of the notion of something going invisible. This can be tightened a little and probably should be if this defect is re-visited to complete the coverage. [MY OVERSIGHT: I overlooked the Errata CD04 treatment of 8.4.4 Detective Operation, the top-level paragraph. The changed form remains obscure, relying on some undiscribed discovery process, detective operations and unnamed relationships. Furthermore, the role of the table:index, if any, in reconciling collisions with detective "operations" on other involved cells is now removed.] I suspect there are defect-report concerns that remain to be addressed in sections 8.4.3-8.4.5. Dennis,
I have added the resolution to the JIRA issue, after having reviewing it again due to your comments. I assume 8.4.5 was named in the report as it refered to the previous hard readable explanation and was therefore related. As the previous text becomes much more clearer after the fix, I believe 8.4.5 do not need a fix itself. From my point of view it is easier understandable now. Frankly speaking, the other concerns you mention are hard to follow. You could help me understanding your concerns, if you suggest a wording to fix the problem you still see (as you did successfully several times before). Thanks, Svante Regarding 8.4.3 Detective
"The <table:detective> element determines how relationships between the current cell and other cells are to be revealed in presentation of the table." versus "The <table:detective> element contains information that is used by an UI to determine the highlighting of relationships between cells or cells that are highlighted due to error conditions." The element does not determine how the relationships are to be presented, e.g. an implementation may use arrows or colors or a dialog or something different. A possible change, if needed, could be " The <table:detective> element contains information about the highlighting of relationships between the current cell and other cells or error conditions. Note: <table:detective> elements are useful for presenting the dependencies among cells on which calculated results and propagated errors are based. " Regarding 8.4.4 Detective Operation: I don't think that can be tightened further. We'd have to ask Patrick why he removed the description of the recursive nature of the discovery process. I think that should had gone into a note instead, e.g. "Note: The same detective operation can be applied multiple times ...". This may also be useful for v1.2-part1. Regarding 8.4.5 Highlighted Range, I second Svante's opinion that the current text is sufficient. [I finally figured out what "SOLUTION PROPOSED BY THE SUBMITTER." It is not a statement, but a title, and it is inclued whether there is any following material or not.]
Eike, I agree it may be valuble to abstract further. "The <table:detective> element determines how relationships between the current cell and other cells are to be revealed in presentation of the table." Perhaps "The <table:detective> element portrays relationships between the current cell and other cells in a manner that may be useful in presenting a visualization of those interdependencies among the cells." - - - - - PS: I also wonder whether there needs to be something said about what this is in terms of a producer and whether, if present, it SHALL represent those relationships as they apply to the document at the point it was produced. I can't imagine that we have anything to say about a transient document and its presentation that is being manipulated by a consumer-producer and has not yet been made persistent in its latest state. Svante, I am not sure what part doesn't make sense. I will wait to see your improvement and will then comment further as appropriate. @Dennis:
Eike and I worked out an answer on this we changed the resolution for <table:detective> to: "The <table:detective> element contains information about what relationships between the current cell and other cells are revealed in the presentation of the table." We dropped error conditions in the wording as they are only a special type of relationship and therefore redundant. Take over your presentation wording, but do not use your suggested: "The <table:detective> element determines how relationships..." As the element is not explaining HOW the relationships are being shown, but only WHAT relationships are shown. Your thoughts on SHALL are not applicable for an errata, but IMHO could be reconsidered for ODF NEXT. Thanks for your help, Svante Errata 02 - ODF 1.2 Reconciliation.
For <table:detective> ODF 1.2 has some useful improvements but still references UI behavior. Reconciliation of that aspect is called for. For <table:operation> the ODF 1.2 definition can be harmonized with Errata 02 in an useful way. The <table:highlighted-range> element was also questioned in the original defect report, but that was neglected in Errata 02. Seeing them togetther in ODF 1.2 makes it clear that the relationship needs to be drawn a little more closely, perhaps related to the Errata 02 handling of table:name as well. Finally, Errata 02 and ODF 1.2 are already reconciled in the definition of the values of the <table:operation> table:name attribute. |
||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Applied
Major
ISO/IEC JTC 1/SC 34 N 1078 : DEFECT REPORT NUMBER JP2-17
