[odf-discuss] A bit more detailed explanation of the AFNORposition

[marbux]

Forwarding this because it bounced earlier.

---------- Forwarded message ----------
From: marbux <marbux at gmail.com>
Date: Sep 26, 2007 8:40 AM
Subject: Re: [odf-discuss] A bit more detailed explanation of the
AFNORposition
To: ODF Discussion List <odf-discuss at opendocumentfellowship.com>



On 9/26/07, Daniel Carrera <daniel.carrera at zmsl.com> wrote:
>
> But if people who know ODF better say that you are wrong, what is the
> problem with that? Or is that "accusing you of falsehoods"?


No, that is another personal attack by you in effect calling me an
ignoramus, relying on your perception of words uttered by people who have
never struggled with non-lossy round-trip interop with MS Office. I work
with people who not only have struggled with it but have actually pulled it
off. And I have studied the situation intensely for a long time, more than
enough to satisfy me that they are right and your sources are wrong.

Your request
> to make ODF applications preserve foreign data not specified in the ODF
> spec is not feasible. Example:
>
> <text:p myapp:zzz="aaa">
>     Foo <text:span myapp:zzz="bbb"> Bar </text:span>
> </text:p>
> <text:p myapp:zzz="444"> Biz </text:p>


This text has non-ODF attributes in a separate name-space ('myapp') as
> permitted by the ODF spec.
>
> Task: Move "Bar" to the second paragraph.
>
> A third-party ODF app cannot know how to preserve these foreign tags. Do
> you copy the zzz="bbb"? Does that make sense outside a zzz="aaa"? Or
> inside a zzz="444"? For that matter, does a zzz="aaa" make sense without
> a zzz="bbb" inside? Maybe the zzz="aaa" has to be changed to something
> else when you remove the zzz="bbb" - but to what?
>
> That's the problem with tags and attributes made by a different company.
> You can't know what they mean. You can't know what to do to "not destroy
> them". Hence, requiring that all ODF applications preserve foreign tags
> that are not specified publicly is asking the impossible.


You're not even on the right track. Try it using a style, e.g., a bold face
foreign attribute; you might get a clue.

And then try studying what I've said before because you are still
mischaracterizing it. Here we go again with another Daniel Carrera straw man
argument. You're working with a mischaracterization of what I said and then
shooting down your strawman. I've never said that *all* foreign elements and
attributes need to be preserved. And I've said repeatedly that the solution
is not so simple as just preserving foreign elements and attributes. The
TC's work on the ODF foreign elements and attributes -- which were
introduced specifically for the purpose of interop with MS Office and other
non-ODF apps -- was never completed because Phil Boutros of Stellant dropped
out.

ODF needs five more generic elements to do non-lossy interop with MS Office
and it could be done either as foreign elements or as RDF metadata. And that
need was submitted and explained in depth to the TC on no less than five
occasions, the first three signed off on by Massachusetts ITD, which Sun,
Novell, IBM, and Adobe knew. The latter two submissions proposed doing it
with RDF metadata instead of foreign elements so Sun would not have to
rewrite SO/OOo. But no joy from the TC. We never even got those proposals
listed as agenda items. They were simply ignored. Had you been reading the
TC mailing list, you would know precisely what those generic elements are
and how to solve what is *your* problem, not mine. Hint: think styles and
generic elements with cascading properties.

The only reason our ODF plug-in for MS Word was not released is the lack of
cooperation on the TC.  We chose not to release it because our goal *was* MS
Office interop with other ODF apps, i.e., OOo. We have no desire to turn
Microsoft Office into the reference ODF editor if it can't interoperate with
another featureful ODF office suite. And Sun has gone to incredible lengths
to block us from establishing non-lossy interop between OOo and MS Office
via ODF, both on and off the TC. Sun won that scrap and ODF is no longer on
our development road map because of it. It just makes me feel warm and fuzzy
all over that you're not concerned enough with that situation to discuss it
but instead want me to tiptoe through the tulips with your latest claim that
what we have already done is impossible.

You continue to claim it is impossible for apps to preserve foreign elements
and attributes needed for interop purposes despite the fact that: [i] the
ODF Conformance section says that conforming apps *may* preserve them; [ii]
in one circumstance says conforming apps *should* process their contents;
and [iii] in another circumstance says that conforming apps must preserve
their content:

Documents that conform to the OpenDocument specification *may* contain
elements and attributes not specified within the OpenDocument schema. Such
elements and attributes must not be part of a namespace that is defined
within this specification and are called foreign elements and attributes.

...

Foreign elements *may* have an office:process-content attribute attached
that has the value true or false. If the attribute's value is true, or if
the attribute does not exist, the element's content *should* be processed by
conforming applications. Otherwise conforming applications *should
not*process the element's content, but
**may* only* preserve its content. If the element's content should be
processed, the document itself *shall* be valid against the OpenDocument
schema if the unknown element is replaced with its content only.

So try working the <office:process-content> attribute into your solution,
Daniel. Is it becoming any easier yet to identify which foreign elements
need to be preserved? Is it just possible that the ODF spec might be amended
to make it even easier to identify which foreign elements and attributes
must be preserved and how they should be processed? Or are you so hell-bent
on proving me wrong that you can't even think in terms of solutions? That's
the view from here. Typical Daniel. You attack me personally and punch your
own strawmen instead of engaging in principled discussion.

Furthermore, you still evade rather than come to grips with the concrete
real-world example of WordPerfect. WordPerfect 6 can still round-trip
documents with WordPerfect 13 without data loss despite the features in WP
13 that were unforeseen when WordPerfect 6 was developed, using an
interoperability framework built around a single generic <unknown> element.
I've had as many as 7 versions of WordPerfect installed on my system
simultaneously to help people troubleshoot their own WordPerfect Office
installations and frequently moved documents between versions. I've only
seen a single misfire in the WordPerfect interoperability framework and that
was with a file that turned out to be corrupt. I fixed the corruption with
the WPLook utility and everything worked fine.

I was fascinated a long time ago with the WordPerfect forward-backward
interop framework and years ago spent a fair amount of time talking to Corel
and former WordPerfect Corp. developers about it. It was one of the major
reasons I knew that the Foundation folk were on the right track despite
naysayers like you, as soon as they explained what they were then doing with
the foreign elements and attributes. And another reason I had suspected they
were right even before I heard their explanations came when I learned that
the ODF foreign elements and attributes scheme was the creation of Phil
Boutros, the interop legend who runs Stellant's stable of over 400 sets of
file conversion filters and associated data conversion apps.

To boot, I have not been talking just about the foreign elements and
attributes. ODF is an interop nightmare. E.g., we had hoped to work around
Sun's indiscriminate destruction of foreign elements and attributes other
than paragraphs and text spans by using the RDF metadata coming in ODF v.
1.2. Here is a fair summary of the major reasons why we changed our mind.
<http://lists.oasis-open.org/archives/office/200708/msg00042.html >.

That is my post including numerous quotes from and links to the Metadata SC
archives, carefully documenting the anti-interop number Sun pulled and the
Metadata SC members' gutless response. Here is Sun's justification for
changing "SHALL preserve" -- which had been made part of the SC proposal at
my request without objections -- to "SHOULD preserve," throughout the
Metadadata SC's work:

> "Similar as other standards (e.g. CSS) we should not try to force features
> by specification, but should let the market sort this out."
>
> Note the not-so-crafty conflation of metadata preservation with feature
support.


Here is what Bruce d'Arcus had to say about that:

"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."***
> >
>
Of course that was before Bruce buckled and supported the Sun amendment
without offering any technical justification whatsoever other than a clearly
erroneous impression that " the language of 'should' is already fairly
strong, basically requiring conformance unless there's an explicit reason
not to do so."  When confronted with the proof that "should" does not have
that meaning in ODF, Bruce admitted that he had something like the RFC 2119
definition of "should" in mind but refused to change his position despite
being wrong about the conformance requirement, saying:

> I agree with the consensus that we cannot reasonably mandate preservation
> of xml:id or other attributes in the spec.
>
> ...
>
> "I think in practice it'll work out quite fine. In the past couple of days
> I've seen public commitments from two major implementors to support the
> metadata proposal; I'm happy to work with them so they do the ***right
> thing*** on the details.
>
> "If they do the wrong thing, they'll hear from me :-)"
>
>
> Of course, Bruce's threat means nothing to corporate bean counters with a
business plan built around cozying up to Microsoft and continuing to
maintain an interop barrier between MS Office and StarOffice/OOo. Vague
commitments to support the metadata proposal say nothing at all about intent
to preserve metadata, relevant conformance requirements, or why Sun wanted
discretion to destroy xml:id attributes and metadata files in the first
place. And "SHOULD" tells both the developers who took part in the
discussion and those who did not that destruction of xml:id attributes and
medata files is perfectly okay. Their apps are still conformant ODF if they
do just that.

In response, I pushed for a "SHALL preserve unless" grammatical construct
and called for use cases demonstrating a need to destroy relevant metadata
and metadata files to fill in the list of needed exceptions. The only use
case offered was user-initiated actions necessitating changes, which would
have been fairly simple to draft as an exception. The justification for the
change deflated in the end to a claimed need to maintain flexibility for
unforeseen circumstances. The 11th hour ambush marched on nonetheless and
the TC quickly rubber-stamped the SC proposal with Sun's anti-interop
changes.

And given that the Metadata SC's work carefully identifies a rather stunning
list of ODF elements corresponding to key MS Office interop break-points
previously added by Sun to the Metadata proposal, for which xml-id
attributes and corresponding metadata files could suddenly be permissibly
destroyed, we dropped ODF from our development road map. Sun and Microsoft
won; to our knowledge no one else was working on non-lossy interop between
ODF apps and MS Office via ODF.

But the real story here, Daniel, is that you have not exactly been taking an
active part in TC deliberations and either haven't a glimmer of what you are
talking about or are being deliberately disingenuous. What you say is
impossible has already been done both by us and many years ago by
WordPerfect Corp. developers. Moreover, the ODF spec already requires
preservation of foreign attributes in one circumstance. More circumstances
need to be identified in the conformance section. But you are arguing
against reality and the ODF specification itself, crippled as it is in
regard to interop.

Most tragically, you have personally offered nothing in the way of a
solution to the interop issues other than claiming without proof that we
don't know what we're talking about. You've been an interop anchor, Daniel,
not an interop propeller.

Moreover, you seem congenitally unable to write a simple email addressing
something I say that doesn't begin with an ad hominem attack and proceed
from there to a straw man argument. I pity you, Daniel. It must be horrible
being so apoplectic that you're unable to engage in principled discussion.

Marbux has already seen examples like this one. I present it for the
> benefit of other readers. I will stop replying to this thread, as I feel
> that it is not productive.


Hooray! That's the right decision, Daniel.You've had nothing constructive to
offer on interop issues in the time I've known you anyway. You do a public
service by standing down and letting those who are working to solve the
interop problems get on with their work instead of being diverted to deal
with your ad hominem attacks and straw man arguments.

Hey, just for the fun of it, I'll give you one back. Are you working for
Microsoft, Daniel? You sure seem to be serving their interests on interop
issues. The foxes are already inside the ODF henhouse and you want to talk
about fanciful reasons high-fidelity round-trip interop is impossible.

There, now I've descended to your level of discourse. How does it feel,
Daniel? Are you feeling all warm and fuzzy inside because I can relate to
you on your own level? How about we just have a nice juicy flame fest with
verbal blood and gore?  You can escalate your attack on my personal
credibility instead of my message and then jump on your straw horse and ride
again! Then I could do another lengthy analysis like I did before of just
how unprincipled your argument is. Wouldn't that be fun!

Not. You are rude, disrespectful, and you write to provoke rather than to
inquire or persuade. You're not happy unless you're on the attack at a
personal level and you lack the basic manners to engage in principled
discourse. You're a born troll, Daniel. If you insist, I'll give you another
therapy session. But I'm through taking your cheap shots silently. Your
choice.


BUCK "MARBUX" MARTIN
  Director of Legal Affairs
  OpenDocument Foundation
  Contact:
<http://www.opendocumentfoundation.us/contact.htm >
-- Universal Interop Now!


-- 
BUCK "MARBUX" MARTIN
  Director of Legal Affairs
  OpenDocument Foundation
  Contact:
<http://www.opendocumentfoundation.us/contact.htm>
-- Universal Interop Now!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opendocumentfellowship.com/pipermail/odf-discuss/attachments/20070927/eef265e1/attachment-0001.htm