Marbux,
You would contribute more effectively to this work if you would become
familiar with modern programming techniques that don't require the byte
for byte sameness that you seem to equate with interoperability. Sure,
byte for byte sameness is one way to achieve interoperability but it is
an extremely limited one and employed mostly by MS VB 1.0 vintage
programmers. Programming techniques and applications have improved a
good bit since then.
The problem with byte for byte compatibility "interoperability"
requirements is that we have to guess "right" at the sweet spot for the
requirements that we mandate that all applications must meet. If we
guess wrong, too few features or too many, then the standard will be
irrelevant to people writing applications.
I am sure one of your complaints, if you could articulate a technical
complaint, would be that xml-id is optional on the elements where it
will appear in the revised ODF standard. Yes?
What that means is that if I want to write an ODF based application that
is solely concerned with adding in-content metadata to a document, say
in a clerk of court office, that processes the file as a stream, adding
attributes and markup as appropriate based on content, I don't have to
support the use of xml-id. And why would I? Oh, yes, because the MS VB
1.0 vintage programming contingent in the ODF TC said that I had to
support it so it would fit their notion of interoperability.
What ODF 1.2 will do, I hope, is provide a set of features that when
implemented support interoperability for features that are implemented
and provide a basis for more sophisticated applications that routinely
support things like use of xml-id. What features are implemented is a
matter of market forces.
Cute, Patrick, very cute. Only it doesn't wash.
Let's see. You begin with an
ad hominem
attack, the insinuation that my knowledge of interoperability is
limited to that of "MS VB 1.0 vintage programmers." Knowing that
ad hominem
attacks are a logical fallacy (and as a former lawyer yourself, you
assuredly do as well), I feel complimented, as I did every time in the
courtroom that an opponent attacked me personally instead of the
substance of my argument. It's like waving a red flag at the judge that
you have nothing of substance on the merits of your position.
Next
you serve your first straw man argument, another logical fallacy,
mischaracterizing my position as being one that argues for
byte-for-byte interoperability. Odd that you didn't bother to link a
post in the archives where I made such an argument, isn't it? Well,
you and I know why you didn't provide a link; it's because I never made
such a ridiculous argument.
But having erected your straw man, you pretend to to demolish it with a
non sequitur, yet another logical fallacy, your premise that round-trip interoperability requires a 1:1
feature match among implementing applications. As to your
non sequitur: First,
your argument fails on its own terms because there are well known ways
to match features even when one app is more featureful than another
using profiles.
See e.g., the W3C Compound Document Formats,
<
http://www.w3.org/2004/CDF/>, with its extensive support for
profiles via an interoperability framework that could feasibly be
incorporated in ODF.
See particularly, the Compound Document by
Reference Framework conformance section,
<
http://www.w3.org/TR/2007/CR-CDR-20070718/#conformance>
User Agent Conformance
- User agents must allow the child DOM to access the parent DOM.
- User agents must allow the parent DOM to access any child DOM. The contentDocument attribute must represent the child document.
- A
conformant user agent of a superset profile specification must process
subset profile content as if it were the superset profile content.
...
In short, no single "sweet spot" of required
features in a file format standard need be identified. There can be as many "sweet spots" as are necessary.
Should
I presume you are ignorant of such programming techniques? You seemed
to personally advocate a "super format" very much like CDF only a month
ago, in a comment at
<
http://www.oreillynet.com/xml/blog/2007/07/can_a_file_be_odf_and_open_xml.html>,
where you said:
"If we could
craft, as both OpenDocument and OpenXML evolve, a standard abstraction
that enables applications that deliver the format desired by a another
application (as well as creating a super format with that mapping) then the overhead of that "extra" ability to interchange would be borne by those who really need it.
"Make
no mistake, I think lossless interchange is an absolute necessity in
many situations, but I am less certain that every application has to
support it. I can easily imagine a public application site that allows
a user to toss a file in the super format at it and the user is
returned a file in a requested format. All of which are XML formats."
Second,
you simply ignore the several previous times, most recently on August
13,
<
http://lists.oasis-open.org/archives/office/200708/msg00033.html>,
when I have described the WordPerfect <unknown> tags that are
used in that application to enable lossless round-tripping of documents
among all versions of WordPerfect from 6.x to 13.x, despite feature
mismatches between the versions, pointing out that it was a scheme very
similar to the ODF foreign elements and attributes, but depended
entirely on unknown metadata not being trashed by one of those
WordPerfect versions. For a more detailed description of the
WordPerfect handling of the <unknown> tags,
see this
post,
<
http://lists.oasis-open.org/archives/office/200707/msg00024.html>.
So lossless round-trip interoperability among apps supporting the same
file format is unquestionably feasible despite mismatches in features
supported by implementing applications, and that is even without
profiles.
Third, what I have actually advocated in regard to
xml:id attributes is the necessity for a "shall preserve unless"
gramatical construct that recognizes as many exceptions as are needed
to accommodate any use case anyone could bring forward illustrating a
need to destroy the atttributes. See e.g., my post here responding to
one of yours,
<
http://lists.oasis-open.org/archives/office/200707/msg00024.html>,
where I said:
"So thus far, we have "SHALL preserve unless destroyed through
user-initiated action." Any other use cases that require exceptions?"
Not once did I ever argue that implementations should be required
to "support" xml:id attributes as you claim. It is a distinction you
recognized yourself during the relevant discussion on the list,
<
http://lists.oasis-open.org/archives/office/200706/msg00137.html>.
Here are your own words:
"I am curious about the term "support" in this context.
"Does preservation of data imply that a feature is supported?
"In
other words, what if I have a very lite weight application that doesn't
actually read any of the content of an ODF file or parse any of the
existing metadata files but simply adds an entry to the metadata
manifest to add metadata about the document as a whole (such as would
happen in a clerk of court's office with filing date, who filed it,
etc.) and added an appropriate metadata file. It then saves *all* of
the file.
"Granted, I haven't implemented a lot of the features
offered by ODF but I have preserved the file, even for features I don't
support.
"Is there a useful distinction to make between
implementation of a feature and preservation of a file's contents that
you are given for processing?
"Granting
that I could also implement a very lite weight application that doesn't
offer metadata or any number of other features since we don't require
an application to implement any specific set of features.
"So,
is preservation separate from feature implementation? (I am asking
because I haven't seen it raised in this context and while it seems
evident to me the two are different, opinions may and probably do vary
on that point.)"
And later, you personally started a
separate thread of that discussion that you titled, "Preservation
question."
<
http://lists.oasis-open.org/archives/office/200707/msg00016.html>.
In fact, the entire debate was about Sun's proposal to remove
the mandatory requirement of preserving xml:id attributes and related
metadata that as I recall you personally added to the draft Metadata
proposal at the request of both Bruce and myself, not application "
support"
of the xml:id attribute feature. As was concisely explained by Bruce
d'Arcus in response to Sun's 11th hour proposal to remove the mandatory
preservation of xml:id attributes requirement,
<
http://lists.oasis-open.org/archives/office/200706/msg00125.html>:
"Preserving
files and attributes is a trivial requirement. Not doing so will
introduce large compatibility problems. Really, just to be clear: if
applications do not preserve xml:id attributes, fields will break, and
any metadata about document fragments will be made invalid. Is that
really in anyone's interest? They need not support metadata in any explicit way to do this."
Bruce later elaborated, <
http://lists.oasis-open.org/archives/office-metadata/200706/msg00066.html>.
"The bottomline is, because we move so
much of the RDF logic into the package, the xml:id attributes become
crucial anchor points. In short, if an application removes, say, the
xml:id from a text:meta-field or otherwise causes the URI binding to be
invalid, the field will break. It would be bad for interoperability for
applications to do this."
And indeed, even Our Illustrious Chairman Brauer agreed it was all
about preservation of metadata, not support for metadata, when he
suggested:
"1. We may move all
the metadata related should/shall language into the general conformance
section. This has the advantage that it is not overlooked as easy as it
would be if it is in the element and attribute description. It further
has the advantage that metadata is mentioned at a very prominent
position.
"2. We may introduce the term of a metadata-aware
application (or something like that), and define conformance
definitions along the following lines for it:
- A metadata aware ODF
implementation *shall* not remove the xml:id attributes defined in
sections [?] or change its values unless the removal or modification is
the result of an edit operation caused be the user, or a similar action
taken by some automatic processing of the document.
- [any other requirement that may exist]
"3.
We may rephrase the above statement for general ODF implementation,
replacing the *shall* with a *should*: - An ODF implementation *should*
not remove the xml:id attributes defined in sections [?] or change its
values unless the removal or modification is the result of an edit
operation caused be the user, or a similar action taken by some
automatic processing of the document."
<
http://lists.oasis-open.org/archives/office-metadata/200706/msg00065.html
>;
see also my response at <
http://lists.oasis-open.org/archives/office-metadata/200706/msg00072.html>.
I
find it very difficult to believe that you simply forgot about that
lengthy debate, Patrick, and the distinction between feature
support and
metadata preservation. But if you respond that you merely forgot, I cannot prove otherwise.
Fourth, atop your
ad hominem attack, your straw man argument, and your
non sequitur,
you stack a use case that is yet another strawman, also premised on
your grosss mischaracterization of my position as advocating mandatory
"support" for xml:id attributes rather than my actual position of
advocating their mandatory preservation, except in specifically
identified exceptional situations that can be demonstrated by use
cases.
In your use case about the court document processor, what is the
resulting harm if your hypothesized application is required by the ODF
standard to preserve xml:id attributes created by another application?
Is it the danger that a judge might open the document in yet another
application that allows her to view the file? Or that she might open a
copy of it in another editor that supports RDF metadata and be able to
edit the document herself, perhaps adding her own annotations complete
with metadata? Or is it the danger that she might use another
application to automatically add hyperlinks links in the document to
the Westlaw database corresponding to the content of the fields in the
document's citations? See e.g.,
<http://west.thomson.com/westcitelink/>.
Of course
you
avoided all need to address such issues
by grossly mischaracterizing my position and then belittling the
mischaracterization. But that was not the only thing you avoided.
"Where are 'the conformity requirements that are essential to achieve the interoperability' in this situation, Patrick?"
<
http://lists.oasis-open.org/archives/office-metadata/200708/msg00022.html>
(my post quoting ISO/IEC Directives). Is your post I am responding to
the best answer you will have to that question at JTC 1, Patrick, when
ODF 1.2 arrives at ISO? You can duck, bob, and weave all you want, but
that won't make the Directives go away.
Fifth,
you top off your stack of logical fallacies with a somewhat wistful "hope:"
"What ODF 1.2 will do, I hope, is provide a set of features that when implemented support interoperability for features that are implemented and provide a basis for more sophisticated applications that routinely support things like use of xml-id. What features are implemented is a matter of market forces."
So your goal is a networked world where metadata is routinely trashed by apps developed by those who are too dumb or otherwise disabled to preserve metadata and only the big boys get to do interoperability, right? So if I send you a document for your editing, I can't count on getting it back with xml:id attributes intact.
No thanks, Patrick. That sounds way too much like how things have worked ever since office productivity software first came on the market. In your world, interoperability belongs only to those who can map features 1:1 with the most featureful apps. And that is precisely why OpenDocument never should have been approved as a standard. Your kind of interoperability makes ODF a
de facto Sun Microsystems standard wearing the clothing of a
de jure standard. Why not just standardize the whole world on Microsoft apps and be done with it? Are two monopolies maintained by an interoperability barrier between them better than one?
Fortunately, we don't have to debate the issue because the Directives resolve the issue. You lose under the rules of the game.
And may i remind you of something else you said, Patrick?
"I have worked for a very long time on
the metadata proposal and I have every intention of ODF having an
interoperable metadata mechanism. I think I know enough about both to
make sure that happens."
<
http://lists.oasis-open.org/archives/office-metadata/200706/msg00061.html>.
When, Patrick, when? And how? By private agreements among implementers?
By an informative best practices guide? ISO/IEC Directives say that
neither are good enough, that interoperability conformance requirements
are mandatory. So why not deal with the problem instead of attacking the messenger?
By the way, I regard my criticism that the Metadata proposal as being non-compliant with the Directives as being constructive. And so was my sarcasm quoted following this post. The former pointed you to an enormous bug in the Metadata subcommittee's work. The latter pointed you more precisely to the sentences that need repair, the ones that are written in passive voice.
Or are you so blinded by your own vision of how you want things to be that bug reports are not welcome?
Best regards,
Marbux
(who still has a stack of personal emails from you addressing me by my given name)