[odf-discuss] procedure at ISO Ballot Resolution Meeting
marbux
marbux at gmail.com
Tue Sep 25 19:39:30 EDT 2007
On 9/25/07, Alex Brown <adjb at adjb.net> wrote:
>
> Marbux,
>
> Just found this while googling for OOXML stuff. Some clarifications below
> ...
>
x--snip--x
I did not "instigate" the group -- I was appointed as chair of the group by
> BSI committee
> (IST/41), which had resolved to establish a technical panel for reviewing
> DIS 29500.
I was apparently provided with erroneous information. Thank you for the
clarification.
I think it's fair to say that the implementability (or not) of a revised
> text was generally not
> a consideration for those reviewing DIS 29500. The general view of
> standards (in the UK) is that
> implementations follow standards, not vice versa, unless there are
> compelling arguments to do
> otherwise.
I have mixed feelings about that, notwithstanding that I believe DIS 29500
never should have been submitted. On the one hand, I would love to see a new
standard drafted from scratch by all concerned. On the other hand, a
standard that has no implementations is a waste of everyone's time. And
taking the macro view, I think DIS 29500 has done a lot of good in terms of
opening people's eyes to just how much the standardization process is in
need of major reform. As an example, I think there can no longer be any
question that software users' interests are severely under-represented.
The rules of admission were determined by BSI. In practice admission to the
> panel was by
> application as much as invitation. Everybody who applied to join (29
> people) was given a place.
> The panel comprised reps from large and small companies, public sector
> organisations, user
> groups, academia and government. No one interest was over-represented and
> (in my view anyway)
> there was a good balance of opinions.
I've only had time for the fastest of skims of the panel's work product.
Based on that, it appeared that the interests of web application developers
were not effectively represented and I felt that Annex I ("eye") to the
ISO/IEC JTC 1 Directives governing interoperability should have received
more attention. The lack of an interoperability framework and
interoperability conformance requirements in both ISO 26300 and DIS 29500 is
also a strong sign that software users' interests were under-represented.
Interoperability is a major market requirement that needs attention. See e.g.,
<http://ec.europa.eu/idabc/en/document/6474>, particularly
<http://ec.europa.eu/idabc/servlets/Doc?id=27875
>. Fortunately, at least India has raised the Annex I issue and I hope the
interop issues move to center stage at the Ballot Resolution Meeting.
Throughout the review BSI was also running an open public comment process,
> and this received a
> large number of submissions exhibiting a wide range of views. Any new
> *technical* comments
> (there were a few) were forwarded to the panel and incoporated into the
> Wiki.
I have a suggestion for such efforts in the future: the invitation for the
public to submit comments and the means of doing so need to be much more
prominent. I was aware of no such ability and the message on the panel's
wiki seemed to be that there was no such process. Had I known there was such
a method, I certainly would have used it.
> and [ii]
> > decreed that all non-technical comments raised at the contradiction
> stage
> > could not be considered because of a JTC 1 ruling (that apparently never
> > existed) holding that that comments raised in support of contradictions
> had
> > been rejected and therefore were not eligible for consideration in the
> > post-contradiction phases.
>
> That is not a correct characterisation at all. The terms of reference for
> the panel were clearly
> set by BSI to be purely technical
> ( http://www.xmlopen.org/ooxml-wiki/index.php/Terms-of-reference).
Again, I appreciate the clarification. I was led to believe that you had a
much larger hand in the panel's formation and in the wording of the terms of
reference.
Questions of contradication,
> law, etc. were handled at a different level within BSI (by a committee
> called ICT/-/1).
In future efforts, this is another fact that needs to be more prominent,
along with the information on how to contact that committee.
What I write is that "the BRM can (effectively) only take decisions on the
> text which can be
> implemented by the project editor. Discussion of legal and IPR issues at
> the BRM is out-of-scope
> and would be pointless. Countries that have concerns in this area need to
> pursue them directly
> with JTC 1, and not wait until the BRM."
>
> In other words, they _are_ on the table -- but JTC 1's table, and not the
> BRM's.
Again, thank you for the clarification. My feelings about you are far less
mixed now.
> That position is also curiously at odds with the BSI position in its
> > comments that all "proprietary" components of Ecma 376 must be stripped
> and
> > replaced with either ODF-equivalents or where ODF has no equivalent
> other
> > ISO or W3C standards. I.e., if patents are off-topic, why did Brown
> allow
> > the BSI group to develop and submit comments that called for removal of
> > proprietary technology?
>
> Good standards build on other standards, and do not reference proprietary
> technologies unless
> absolutely necessary. That's just basic good practice.
But the point here is that no one knows which portions of DIS 29500 are
proprietary, or rather, that we know what some of the proprietary portions
are but do not know how much more is proprietary. I recognize the
distinction between referencing and incorporating, but the market
requirement for an unencumbered standard does not.
Well, that certainly is "reading between the lines" because I am content to
> leave legal
> determinations to lawyers, any haven't paid any attention to Ecma's
> letter.
I'm a retired lawyer and my involvement in standards work has convinced me
that much of the ISO/IEC standardization process is operating outside the
bounds set by the Agreement on Technical Barriers to Trade and precisely
because lawyers are not being involved in the process.
For example, section 2.2 provides in part: "Members shall ensure that
technical regulations are not prepared, adopted or applied with a view to or
with the effect of creating unnecessary obstacles to international trade." <
http://www.wto.org/english/res_e/booksp_e/analytic_index_e/tbt_01_e.htm#article2A>.
And the treaty says nothing about technical excellence at all. DIS 29500
should have been filtered out at the contradiction stage because beyond
question it was created both with a view to and the effect of creating such
obstacles. E.g., it was a single-vendor solution and has unquestionably
slowed adoption of the existing international standard in the area, ISO
26300. So its mere preparation has had the prohibited effect.
And one could certainly raise a very strong argument that the very purpose
of standardization is to promote competition by commodifying markets. Yet
the prevailing custom in standardization bodies is to cry foul if anyone
raises issues having to do with effects on competition. Moreover, the
process actually used is heavily weighted toward approving standards whether
they will have anti-competitive effects or not. E.g., ISO 26300 never should
have been approved without an interoperability framework and
interoperability conformance requirements. As it is, OpenDocument is a Sun
Microsystems de facto standard garbed in a de jure standard's clothing.
> Brown's justification is that only technical issues can be resolved during
>
> > the Ballot Resolution phase.
>
> I don't know what this "phase" is, exactly.
My understanding is that a lot of negotiation and lobbying goes on behind
the scenes in the run-up to the BRM. That is what I meant by "phase."
To repeat, I wrote that only technical issues could
> be resolved at the ballot resolution _meeting_. The result of that meeting
> can at most be
> editing instructions for the text itself which the editor must obey. The
> meeting cannot instruct
> him to reveal (for example) MS patent information, because it's not in his
> power to do so, and
> especially not by editing the text of an ICT standard!
To repeat: countries that have concerns in this area need to pursue them
> directly with JTC 1.
Am I wrong that NBs may vote again at the BRM? I see no rational way for the
law to be divorced from the facts (technical issues) in a legislative-like
setting, particularly when the Agreement places the responsibility for
adhering to it with the member nations, not with JTC 1 or ISO/IEC.
I realize that much of the reform of the standardization process must await
another day, but a position that only technical issues may be resolved by
the NBs at the BRM runs squarely counter to the treaty.
> on a slow track. But none of the NBs that raised contradictions, BSI
> > included, objected to the procedural violation despite it being an
> > appealable decision to the ISO/IEC Secretariats under the JTC 1
> Directives.
>
> You're guessing at what went on between NBs and JTC 1.
Yes and no. I've got my ear well to the ground and believe I would have
heard a rumble had there been an objection.
Again, IANAL, but my understanding is that the consensus view is that JTC 1
> did operate in
> accord with the Directives, and that an important distinction in them
> needs to be understood
> between "addressing" and "resolving" issues. I hope to blog on this topic
> some time.
I'll look forward to reading it. But this is an issue I researched at the
time and the JTC 1 rule that allowed it was only a proposal that had not
even been voted on when the decision was made to keep DIS 29500 on the fast
track despite the contradictions. And the effect of the rule when adopted
was to make the contradiction process irrelevant while leaving it in place.
To one who worked long and hard on the contradiction issues, the situation
reeked.
I'm attempting to understand the process and apply the rules as best I can.
> While wondering
> quite why I'm doing this...
>
I appreciate your best efforts. You've undoubtedly been handed a hot potato.
Best regards,
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/20070925/5a00eddc/attachment-0001.htm
More information about the odf-discuss
mailing list