d140602
nfoWorks
devNote
RCT Extension
Down-Level Resiliency
Diary & Job Jar
|
|
d140602
nfoWorks
devNote |
Status |
Date |
Description |
|
| done | 2014-06-29 |
|
|
| 2014-07-09 | Mine the ECT list for use cases and see which ones apply for resiliency testing now. | ||
| 2014-07-09 | Make some style changes and figure out how they are reversible in actual implementations. | ||
| 2014-07-09 | Create a set of layout-changing tests where only layout changes and no text is involved: paragraph breaks and joins, joins across paragraph types (<h>,<a>, <p>). breaking and joining larger items such as list items, lists, indenting, outdenting. Find other classes of such layout cases, perhaps involving numberings, bullets, and other hanging and indent-varying effects. | ||
| 2014-07-08 | Figure out how to provide accession-based names for the contents of d140602-suite. I can go to a decade systems, such as d140602-nn, and that could roll up into alphanumeric cases if necessary. | ||
| 2014-07-08 | I don't know if d140602-suite needs a construction zone or not. The question is whether or not d140602a (this page) will be over-burdened or if it is best to manage the set. I don't think going down to a full set of sub-folios is a great idea. | ||
| 2014-07-08 | Some suite items may merit their own pages. This is going to lead to subpages or subfolders. A page, such as one for CT-2014-07-02, might explain "what is going on here" and how the round trip fails. This is interesting because there are a couple of possible ways to implement the change without RCT, and it is worthwhile to test that case with the possible optional RCT as well (in the extension profile testing). | ||
| 2014-07-06 | Capture the CT-2014-07-02 Cross-List-Cut case in the d140602-suite. | ||
| 2014-06-29 | Mobile and tablet apps are also significant here. | ||
| 2014-06-29 | These can also apply in conversion and interoperability situations. Should look at OneDrive and the Google stuff as well. Also, don't forget WordPerfect and other products that offer quasi-native and non-native support. | ||
| 2014-06-29 | The resiliency documents should also test against validators to see what happens. This will matter with respect to how "strictness" is dealt with. "strict" in the ODF 1.2 case is used to mean without extension. It is clear what that means in the assessment of a document and in claims about a producers. It is meaningless with respect to consumers, who are not required to interpret all provisions of the format, strict document or not. The complexity of provisions in ODF makes it unclear how one can characterize the comprehensiveness of a consumer. | ||
| 2014-06-29 | There needs to be a glossary of terms. It can provide the glossary section for the extension profile specification as well. Hook up to it when something is available. | ||
| 2014-06-29 | Resiliency is appropriate instead of robustness, because foreign extensions are not errors. However, ignoring them is a should, not a shall. Programs that fail are perhaps, stubborn? We could look at this as rigidity or flexibility though. I need to see if I can become unattached to resiliency. I'll give it a few days. | ||
| 2014-06-29 | Link to interoperability cases when that collection is established | ||
| 2014-06-29 | Link to application robustness cases when the collection is established. Robustness might not be the case. It might be variance. Although, depending on how failure happens, that is a robustness issue as well. | ||
| 2014-06-29 | There may need to be a way to indicate the results of resiliency testing in a neutral way (i.e., with no indication of what products provided what results), and with allowance for retesting. The details against individual products/versions will need to be embargoed/sequestered. Anyone can apply their own product configurations to the test documents. The goal of my use of the tests is simply to determine and present the state of the world, not provide information that could be used in competitive posturing. | ||
| 2014-06-29 | A means for organizing tests against important interoperability cases is also called for. There needs to be a means for identifying where coverage is desired and accounting for results in resiliency tests. | ||
| 2014-06-29 | Also to be covered in the folio is anything on how the resiliency test documents are constructed, disseminated, applied, etc. Procedural stuff. | ||
| done | 2014-08-29 | d140602-cache: Complete customization and readiness. | |
| done | 2014-07-08 | d140602/c: It is important to include what are bugs in the context of RCT. These deviations are treated as bugs for the purposes of the down-level resiliency guide. | |
|
done 2014-07-08 |
2014-07-06 | So failed documents are also part of the collection. They might be bugs and bug fixes would be appropriate, and they might be behaviors that can be captured better another way and also another way supplemented with RCT. | |
|
done 2014-07-08 |
2014-07-06 | There are also failures, where tracked-changes don't round trip with the same producer, and where the tracked change does not have enough information to revert properly. These count as resiliency cases and so there are three flavors - the original document, a document that captures the changes perhaps more successfully, and how that document would work better with RCT markup, first with resiliency material and later with the actual markup. | |
|
done 2014-07-08 |
2014-07-06 | d140602-suite/default.htm Complete Customization. Then link from d140602 folio cover. | |
|
done 2014-07-06 |
2014-06-29 | d140602-cache or similar is needed for the collection of individual cases and their downloads (just to make the dev/2004/06/ level more manageable and not too cluttered. [I think the need is for d140602-suite and d140602-escrow or -sequester.][dh:2014-07-06 Definitely d140602-suite.] | |
|
done 2014-07-08 |
2014-06-29 | Indicate that resiliency tests may also reveal bugs and variances against the ODF 1.2 CT provisions. Such cases would become candidates for testing the application profile as well. A kind of quality of the null-implementation case. They are automatically interoperability cases as a consequence. | |
| done | 2014-07-01 | d140602-b/c Diversify titles along lines of d140603. | |
| done | 2014-06-29 | d140602: Connect from Faux Namespace and the Development page immediately. | |
| done | 2014-06-29 | Make placeholders for d140602, d140602a, d140602b, and d140602c | |
| done | 2014-06-29 |
Create this page ready for recording Diary & Job Jar items of this devNote. |
|
created 2014-06-29-09:54 -0700 (pdt) |
