On Thu, Jun 12, 2008 at 6:54 AM, <> wrote:
jose lorenzo <>
wrote on 06/12/2008 12:26:37 AM:
> To repeat more clearly, don't expect to succeed in
> withholding the "conformancy" label from any monopoly
> vendors wanting to embrace and extend with intent to
> extinguish. Instead, look towards this work with OASIS
> as a way to make things easier on groups that really
> do want to standardize and interoperate.
>
First there is no way that a standard
can distinguish good, competitive, progressive, innovative extensions from
evil, monopolistic, embrace and extend extensions. If we disallow
all extensions, then we essentially say that every word processor must
have the same feature set (You can have any color you want so long as it
is gray). We would also would prevent the ability of mixing ODF with
other markup languages, even if they were open standards as well.
The C (Programming Language) standard is a treaty between the developers of C compilers and programmers writing C programs (to be compiled by those compilers). It lays obligations on both parties. It requires programmers to stick to certain rules when writing C code. It requires compiler writers to provide certain functionality. It also lays down certain areas that are defined by a particular implementation (compiler) - the standard itself doesn't say what the behaviour must be, but it does say that the compiler writer must define what the behaviour of their compiler is. Sometimes it lists the options -- other times, it does not. Further, it provides information that tells a programmer which parts of their code may work differently on different implementations, and which parts of their code will work the same on all (conforming) implementations.
Translating from C to ODF, that would mean that the standard is a treaty, first and foremost between users of ODF-compliant software packages and the developers of those packages. Secondarily, it would give some information about how different packages would treat the same ODF-compliant file - where there would be differences (e.g. fonts) and where there would be commonality (section headers need to be distinguishably be section headers -- possibly a poor example, but the best I could come up with on the spot). Adopting this view of the world, ODF would tell users that if they stick with certain features, then the documents they produce will be portable between ODF software packages. If they insist on using some other features, the portability of those documents will be reduced. This helps everyone - it limits the workload on the writers of the software packages (they do not have to handle esoteric extensions that are outside the standard), while providing users with both guarantees and warnings. Of course, there are difficulties with how to actually indicate which features that a user is using are not strictly ODF conformant - or are in nebulous territory - is hard; very hard.
For example, I've heard a lot of interest
in mixing XBRL, the now-mandated markup language in the US for annotating
security filings, with ODF. But if ODF cannot allow other markup
in a foreign namespace, then this could not be done.
Pardon me if my inexperience with XML shows through, but is this not stuff that would be handled in some way by XSLT or an equivalent piece of technology. That is, if you use an XML 'Schema' (is that the correct word for things like XBRL?) in the ODF document, then you also need to provide something that provides appropriate formatting guidelines for that material -- in my limited understanding, that something being an XSLT or similar specification of how to transform and treat the 'higher level' (XBRL) notation into a 'lower level' formatting notation (is taht ODF. or something working at a lower level than ODF?).
So in the end, if we try to make moral
distinctions in the standard, we'll be continually frustrated. We
cannot force anyone to do anything. All we can really do is make
definitions and give them a label, and hope that these definitions have
enough market relevancy that they are adopted.
This is where the treaty comes in...The standard will specify what both sides can expect, and where both sides can innovate. Where the sides are the ODF software writers and the ODF software users.
However, we do have a number of tools
available to us, to make these kinds of distinctions. For example,
there was a suggestion yesterday to define an ODF/A profile for archiving,
analogous to PDF/A. This profile would forbid certain non-portable
constructs in ODF documents conforming to this profile, among which I assume
would be extensions.
Similarly, the concept of "strict
conformance" is already well-defined. This is defined as:
"Strict Conformance – conformance
of an implementation that employs only the requirements and/or functionality
defined in the specification and no more (i.e., no extensions to the specification
are implemented)." (http://www.oasis-open.org/committees/download.php/305/conformance_requirements-v1.pdf)
So the proposed committee, when creating
a conformity assessment methodology document could certainly do so from
the perspective of strict conformance as well as general conformance. But
again, we're defining, we're not mandating. It would be up to our
audience -- the procurers, vendors, users, etc., -- to determine
which mode of conformance was important to them.
Again, using my analogy, there are strictly conforming C programs, and conforming C programs, and non-conforming C programs. There are also conforming and non-conforming implementations, not that the standard can dictate anything that a non-standard implementation does. Similarly, it can impose no limits on a non-conforming program. What it can and does state is that a conforming compiler is not required to translate a non-conforming program; the extent to which a compiler does translate a non-conforming program is a QoI (quality of implementation) issue.
Does any of that make any sense?
--
Jonathan Leffler <> #include <disclaimer.h>
Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org
"Blessed are we who can laugh at ourselves, for we shall never cease to be amused."
