On Thu, Jun 26, 2008 at 8:55 PM, marbux <> wrote:
I propose that, amongst other tasks, the OIIC TC be tasked with
providing a set of profiles that clearly and unambiguously specify the
conformance requirements essential to solve the following use case.
1. DEFINITIONS and MARKET CONDITIONS:
Market A is that for ODF mobile device editors and all competitors in
that market each have unique implementations of ODF that support ODF
to varying degrees.
Market B is that for ODF web editors and all competitors in that
market each have unique implementations of ODF that support ODF to
varying degrees. The range of ODF features supported in this market is
broader than that in Market A.
Market C is that for ODF outliner editors and all competitors in that
market each have unique implementations of ODF that support ODF to
varying degrees. The range of ODF features supported in this market is
broader than that in Market B.
Market D is that for medium-capability ODF editors, e.g., KOffice, and
all competitors in that market each have unique implementations of ODF
that support ODF to varying degrees. The range of ODF features
supported in this market is broader than in Market C.
Market E is that for the most featureful ODF editors and and all
competitors in that market each have unique implementations of ODF
that support ODF to varying degrees. The range of ODF features
supported in this market is broader than in Markets D.
In each of Markets A through E, each competitor's ODF implementation
writes application-specific foreign elements and attributes in the
application's unique ODF namespace and is incapable of writing to
unextended ODF.
Market F is the ODF market for integration of ODF implementations with
service-oriented architectures at the enterprise level in business
processes that maintain, manage, and process silos of legacy data
stored in formats other than ODF. Integration of ODF implementations
in this market requires ultra-high fidelity interoperability for,
e.g., automated document assembly that (in oversimplified terms) [i]
parses and extracts data from not only ODF formats but also a host of
other formats in the assembly of a given document; [ii] in the
assembly of a given document converts/transforms all relevant
extracted data from multiple different formats in any combination to
an intermediary common data format; [iii] formats all assembled data
into a new document in the desired output format; and [iv] serializes
that output to the next application in the business process chain,
whether an editor or a viewer.
Sorry to say these splits really open high risks.
Online Office suite where does it have to render and so on.
A threw to F need to be treated the same. Of course some of ODF lack of features do effect B.
Important thing here single set of rendering rules can be created for the lot. As so as you start doing special treatment you have a mess.
Now if A or B or anyone of those groups need something special it should be entered into the standard and all tools that render to screen should be able to render in as many ODF modes as able. So if I am sending to a modile device from Open Office or web base office I can see how the end user will see it.
Zero split. Strict rules no loop holes no fragmentation. All this is putting forward are loop holes that will create fragmentation.
Note warping ODF for A or B is not covered in standard anywhere I can read. So anyone doing it is in breach of standard. So need to put forward standard expands to cover what they are doing.
Peter Dolding
