RE: [oiic-formation-discuss] The importance to users of documents looking the same

["Hurley, Garry \(L&I - OIT\)" <ghurley@state.pa.us>]

Paul,

I don't want to get on your bad side here, but CDRF specifications sound like they are beyond the scope of this discussion list, which was, I thought, to determine whether or not a TC needed to be formed and to write a charter.  Suggesting that the TC consult the CDRF specifications as a guideline is all we should really do at this point - unless we decide that no TC needs to be formed, then I assume the standards process would fall upon the shoulders of OASIS in general.  Rob, am I off-base here?

I admire your passion for CDRF, and if it is a viable standard, good luck in getting it past the group.  I am, however, constrained to point out that my email messages are limited to about 2 MB in length and what attachments are acceptable are also limited in length.  (You should see what we have to do to distribute a file to our colleagues!)  Anyhow, your emails do tend to be lengthy ones, as do mine.  I would really like to stick a fork in the argument of tying down a TC's options too firmly.  Yes, they should be given a general purpose, and a starting point.  That is all we should do.  Personally, I prefer to look at this from a developer's viewpoint.  "Give me the standard, tell me what has to go into the file, how to arrange the data, and the name of the file and I will give you the file with everything in its place."  Let's work on getting the TC what they need to deliver those standards to me, okay?  This group was not tasked with creating a standard, just desciding whether or not we need a committe to decide it, and what that committee's responsibilities will be.  Judging from the traffic on the list, I would say yes, we need one.  Now, how much freedom do we want to give them to develop these standards?

Rob, or anyone for that matter, do you disagree that we need a TC?  Do you agree or disagree that we need to have some guidelines for them to follow?  I saw a proposed skeleton for guidelines put forth earlier.  I put forth several tasks earlier.  I humbly suggest we all decide what additional tasks we are going to place on the list for the TC.

Garry L. Hurley Jr.
Application Developer 2
Office of Information Technology - Bureau of Application Development
PA Department of Labor & Industry
651 Boas Street, Harrisburg, PA 17121 
Phone: 717.506.9373 (UCMS) or 717.346.9799 (Harrisburg)  Fax: 717.506.0798  Mobile: 717.649.0597
www.dli.state.pa.us <http://www.dli.state.pa.us>


My comments do not reflect those of the Commonwealth of Pennsylvania, its various agencies and departments, or its citizens.  They are my own, and may or may not be shared by those in positions of authority over me.


-----Original Message-----
From: marbux [mailto:marbux@gmail.com]
Sent: Wednesday, June 18, 2008 5:24 PM
To: oiic-formation-discuss@lists.oasis-open.org
Subject: Re: [oiic-formation-discuss] The importance to users of
documents looking the same


One of the advantages of CDRF as an interop framework is that you can
have multiple branches of progressively more featurerful profiles and
the branch can begin at any profile.

E.g., one branch for the pixel perfect folk, another for those whose
concern is for automated parsing, extraction, transformation, and
reformatting. Because CDRF species RFC 2119 as the reqirements
keywords definitions, the modal definition of "may" requires that the
pixel perfect implementations retain the ability to write to the
unextended profiles. <http://www.ietf.org/rfc/rfc2119.txt>.

That's the problem that the ODF TC and Rob have been ducking ever
since I raised it on the TC. JTC 1 switched ODF from RFC 2119
definitions to ISO/IEC Guideline definitions but didn't even look at
the consequences. Every interop requirement in ODF got toggled off by
the switch of a couple of words.

E.g., the sentence in the conformance section that says
implementations "may" write foreign elements and attributes
(app-specific extensions to ODF) lost the requirement that
implementations retain any ability to write to unextended ODF. So now
we have no major ODF apps that can still write to unextended ODF.

It's this kind of messiness and laxity in the ODF spec that will make
the profile work of this TC so difficult and why we can't maintain
compatibility with current ODF implementations as presently
implemented in the profile work. It's the apps that are going to have
to change, not the profiles if we want to achieve interop and
application-neutrality.

I suspect thatis why Rob rejected out of hand my proposal that this TC
be required to use RFC 2119 definitions rather than ISO/IEC Guideline
definitions and why he is pushing for two classes of conformance for
the profiles, strict conformance and tag soup conformance. IBM does
not want all those folks who have built their ODF software businesses
on OOo and its clones to have to strictly conform to the profiles.
That would force the reprogramming of OOo and its clones to actually
achieve interop. IBM wants ODF to continue to be defined by OOo, for
the OOo implementation tail to wag the ODF standard dog.

IBM and Sun don't walk the ODF interop walk; they just talk the ODF
interop talk. I've experienced that time and again and that is why I
am insistent on specifying CDRF in the TC charter.

I've heard far more enough of the ODF interop talk. I want to see that
first step on the ODF interop walk. CDRF forces the ODF interop walk.
That's why IBM doesn't want CDRF specified as the interop framework
for the profile work. IBM just wants to talk about ODF interop. IBM
does not want to allow it to happen.

I note again that this is not a personal attack on Rob. I have genuine
affection for Rob and fully comprehend that he is not the guy who has
the power to change IBM's anti-ODF-interop policy. Rob can't disobey
without putting his job and retirement benefits on the chopping
block.I shoot at the reprehensible company policy, not at Rob.

Best regards,

Paul E. Merrell, J.D. (Marbux)

-- 
Universal Interoperability Council
<http:www.universal-interop-council.org>

---------------------------------------------------------------------
To unsubscribe, e-mail: oiic-formation-discuss-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: oiic-formation-discuss-help@lists.oasis-open.org