Issues List.
List of unresolved Issues:
- Which version of ODF are we testing? 1.0 or 1.2?
- Full-featured editors available that are capable of not generating application-specific extensions to the formats?
- Interoperability of implementations mandatory?
- Interoperability between different IT systems either demonstrable or demonstrated?
- Profiles developed and required for interoperability?
- Methodology specified for interoperability between less and more featureful applications?
- Specifies conformity requirements essential to achieve interoperability?
- Interoperability conformity assessment procedure(s) formally established and validated?
- Document validation procedures valid?
- Specifies an interoperability framework?
- Vendor-specific extensions classified as non-conformant?
- Preservation of metadata necessary to achieve interoperability mandatory?
- XML
namespaces for incorporated standards properly implemented? (ODF-only
failure because Microsoft didn't incorporate any relevant standards.)
- Optional feature interop breakpoints eliminated?
- Scripting language fully specified for embedded scripts?
- Hooks fully specified for use by embedded scripts?
- Standard is vendor- and application-neutral?
- Capable of converging desktop, server, Web, and mobile device editors and viewers?
- How do we address the "interoperability" issue with
regards to presentation, if we cannot guarantee the same fonts will be
available. Do we make that a condition of testing - all tested
platforms have the testing font available? But does that become a
meaningless test for an end user who encounters this but is not aware
of the issue? After all the document will look different, so the
"interoperability" test will be a failure for that user. (as a
tech/developer, I see obvious answers here - i.e. install the font.
But to the general public/end user, this may not be so obvious.)-Shawn.
- How to define 'layout perfect' or 'pixel perfect' to facilitate an unclear idea of looking the same.
- How to define a tool to compare a reference document as processed by n vendor tools
- Can ODF instance normalization help with comparisons?
- How to process 'may' clauses in the standard. See note [1] below.
Notes.
[1] 2008/6/23 RD wrote:
the idea is that a "may" clause means that the application is not obliged to use that rule, but if it does, then it must follow the spec.
In that case, test results would be:
a) not implemented - the application does not implement that clause
b) pass/fail - the application does implement that clause, but it does or does not fully follow that clause specification.
In that case there's no uncertainty about the clause, it can be not implemented at all - which is fine, implemented and Ok - which is fine as well, or implemented, but badly - so developers should do something about that. As for users, they need to know whether their app doesn't implement that at all, or it does - and how good their app implementation is (Ok/not Ok).
DP: Propose that for 'may' clauses, if the test is run, a warning is output rather than a test failure and any fail result will not cause an overall test failure
Ideas.
Could the ideas of C19N and normalization be of use to the TC
Those links you provided are actually very close to what I mean by "normalizing" an ODF document. Perhaps "Canonicalizing" an ODF document would be a better term. The W3C spec you point to also coin a nice phrase: "logically equivalent". That's exactly the term I'm looking for all this thread :-)
Two ODF documents that differ only in the names of the automatic styles (but the content of those styles are the same) are logically equivalent. The ODF spec explicitly says that an application is free to change the names of the automatic styles (but not the manual styles!)
Two documents that differ only in what order the image references appear in the manifest are logically equivalent. The spec dictates nothing about the order. It's not important because it's a set, not a list. As long as they contain the same references, they're logically equivalent.
|
|
