OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

topicmaps-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [xtm-wg] From the chair of TopicMaps.Org


[Eric Freese, Chair of TopicMaps.Org:]

> The TopicMaps.Org process is stated in the charter. A publication
> becomes final when it is approved by 2/3 of the participating
> members. As chair (acting) at the Paris meeting, I ruled that a
> qualifying vote did not occur at the Dallas meeting (not enough
> members present) or at any time prior to December 4 or at any time
> before the Paris meeting.

[Steve Newcomb, founding Co-chair of TopicMaps.Org:]

Michel Biezunski and I do not accept this revisionist ruling, which
impugns the integrity of the leadership that we provided in getting
the Core Deliverables delivered on time and as explicitly directed by
a 2/3 majority vote of the Participating Members of the XTM AG, just
as the Charter requires.  We received the full authority of
TopicMaps.Org to publish on December 4, by means of a 2/3 majority
vote at the Dallas meeting in November.  The oft-repeated accusation
that we abused the process set down in the Charter is entirely false,
and the written record shows it.

Even though the record shows that Michel and I clearly acted in the
best possible faith, procedurally speaking, let's ignore the
procedural stuff, and get to the heart of the matter.

For us, the whole idea of XTM has always been to provide a technically
solid foundation *quickly* that supports true federation of finding
information, so that a diverse topic map industry can start growing
*as soon as possible*.

The only reason to create a new independent standards-making body like
TopicMaps.Org is to go fast, and the only reason to go fast is because
a window of opportunity will close sooner than a go-slow process can
deliver the goods.  (TopicMaps.Org has still not delivered the goods,
but it could have, by now.)  When we founded TopicMaps.Org, there were
plenty of go-slow options, including the ISO process, where we already
served (with Martin Bryan) as editors of the ISO Topic Maps standard.
We perceived, and we *still* perceive, that certain intellectual
property related to topic maps must be given to the public *quickly*
in order to maximize public benefit.  There are several reasons for
believing this, including the nascent Semantic Web initiative of the
W3C, the DARPA Agent Markup Language initiative, Doug Lenat's plan of
progressive gifting of critical pieces of Cyc to the world, and the
widespread acutely-felt need for a vision that solves the general
problem of finding and using *all* business data and metadata.  If the
ideas of topic maps are going to make a difference, this is the time
when they must be contributed in a way that will have mass relevance.

The first XTM meeting after the December 4 delivery date was in
January in Paris.  We intended the order of business at that meeting
to be a discussion of how to finish the Specification by converting
what had been delivered in draft form into final form.  I'm not sure
that anyone other than the editorial team -- Michel, Sam Hunting,
Murray Altheim, and I -- had even read the draft portions of the Spec,
because not one substantive question was asked about them.  What was
discussed instead, at great length, was whether Michel and I had
exceeded our authority as chairs and editors in actually meeting the
deadline that we had been required, at the Dallas meeting in November
by a 2/3 majority, to meet.  In the course of these discussions, two
rulings were made by Eric Freese, who was acting as our
parliamentarian.  One of the rulings was that the resolution taken at
the Dallas meeting, which authorized the editors to deliver, at
minimum, the "Core Deliverables", had been inconsistent with the
Charter's requirement that all final text be subjected to a 2/3
majority vote.  (Never mind that there was absolutely no other way to
meet the December 4 deadline than to authorize the editorial team to
use its best judgment.  And never mind that meeting the December 4
deadline had the effect that the W3C suddenly took topic maps very
seriously, as had been predicted and desired.)  Eric's second ruling
was that there really hadn't been a 2/3 majority vote at the Dallas
meeting, because the written proxy of Patrick Durusau, which Patrick
had granted to me personally, could not properly be voted by me.
There was nothing in the Charter about proxy voting, and nothing in
Robert's Rules, either.  Eric's ruling left the Dallas meeting
retroactively incapable of generating a 2/3 majority; under the
retroactive rulings, the actual vote was short of a 2/3 majority by
one fiftieth of one vote.  Thus the whole Dallas meeting -- the
meeting that authorized the December 4 deliverables -- was
retroactively rendered inoperative.  (This ruling is particularly
incomprehensible given the fact that the whole XTM Authoring Group
stood in front of the XML 2000 plenary on December 4 saying, in
effect, "Here are the Core Deliverables, here we stand united, and
this is our mutual accomplishment.")

Michel and I pointed out that a process that requires every editorial
change, including changes for consistency, to be approved by a 2/3
majority simply can't work rapidly.  In that meeting room in Paris, it
dawned on us that there would never again be a 2/3 majority supporting
any editorial discretion whatsoever.  Believing that the group could
not make rapid progress with this new no-editorial-discretion process,
we decided that it was very unlikely that we could meet our next
deadline for release of the XTM Specification.  Accordingly, we
offered to produce a Spec that would at least be on time, even if it
wasn't sanctioned by the XTM Authoring Group.  This idea was greeted
with very little enthusiasm, just as one might expect.  Nevertheless,
left with no other viable options, Michel and I withdrew to do exactly
that.  My final remark to the group was, "Good luck with your
deadlines."

And the group did find its own way!  Suddenly it became possible to
meet the February deadlines!  People who had been in the go-slow camp
moved suddenly into the go-fast camp.  A finalized Spec was prepared.
But, alas, it turned out that the finalized February 17 Spec was a
go-slow Spec.  Rather than resolving the confusion over what topic map
information means, the February 17 Spec prolongs the confusion, and
refuses to address the heart of the matter.  Instead, it provides new,
circular syntax-defined-in-terms-of-syntax "equivalences", rather than
any rigorous expression of the meaning of topic map information.  And,
to make matters worse, the new, February 17 Spec isn't even consistent
with itself in the most basic aspects of a standard; Annex F is
described as "informative" rather than "normative", but the
Conformance Clause requires conformance to Annex F.  (And Annex F is
where the "equivalences" are found.)

Let's enumerate some of the ways in which the XTM Authoring Group has
been inconsistent with itself:

(1) Decisions taken at one meeting, on the basis of which many people
    made significant investments of time and money, were ruled
    inoperative at the next meeting.  (Too bad for those who made made
    substantial sacrifices to meet a tight deadline, as directed by a
    2/3 majority vote.)

(2) The DTD, Conformance Clause, and Published Subjects that were
    published on December 4 as being dependable, with the statement
    that they would not change in ways that might render existing
    conforming applications non-conforming, were *all* changed in ways
    that would do exactly that.  Maximizing confusion, both versions
    of the Specification are labeled "1.0".  (Note: The DTD was
    changed only in minor, error-correcting ways, and Michel and I
    fully support those changes.  But the wholesale deletions of the
    fundamental Published Subjects, and the Conformance Clause's
    newfound allegiance to Annex F, are really radical changes.  Prior
    to approving the February 17 Spec, when I complained that Annex F
    was misleading, I was assured by one of the new editors that Annex
    F was merely informative, so I shouldn't worry about it.)

(3) The Charter was explicitly designed to support a "go-fast"
    process, with broad executive authority granted to the
    editors/chairs.  But in practice, the group actually follows a
    "go-slow" process, in which it's not critically important for
    participants to be prepared for technical work at each meeting,
    and where meeting time can be dominated by discussions of
    procedural issues, rather than by technical matters.

> Every other participating member at the time voted for the
> specification, including Steve and Michel. If there are errors in
> the spec, we all share equal blame. I certainly hope that all the
> participating members reviewed the document as closely as I did
> before casting their "YES" votes. That being said - if there are
> perceived errors in the spec, I would very much appreciate it if
> those errors were identified so that they can be resolved.

What Eric says here is absolutely right.  It is my fault that I never
checked the Published Subjects or the Conformance Clause before voting
yes.  True, I never imagined that a Published Subject would be deleted
from the XTM Spec.  What possible purpose could be served by deleting
a Published Subject, especially after the claim was made that nothing
would change that might invalidate a conforming application or topic
map?  I did read Annex F, and I complained about it, but I was told by
one of the editors that it was merely informative, and I did not check
the Conformance Clause, which references Annex F as normative.  So I
am guilty of failing to check everything with a microscope before I
voted.  Knowing what I know now, I never would have voted "yes".

> A decision that was made in Paris was that the processing model
> would not be ready for publication given the timeline
> presented. This included dropping templates from the specification
> and PSI documents. The changes to the PSI list were made in
> accordance with that decision since it seemed reasonable to drop
> PSIs which were not going to be covered in that version of the spec.
> It has been said that to do so makes the current XTM spec
> incomplete. I would maintain that it no less complete than the ISO
> standard, which does not have any PSIs declared for it.

"Editorial consistency" is the reason given for the deletion of the
Published Subjects.  The truth is, however, that keeping the Published
Subjects would not have interfered in any way with the February 17
version; they just would not have been explained.

Eric's comparison of the ISO standard's lack of PSIs with the XTM
Spec's deletion of PSIs is specious in other ways, too.  The XTM Spec
is supposed to nail down the things that the ISO standard deliberately
leaves open.  The requirements of the two standards are different,
especially in that specific way.

> The PSI list on December 4 Core document also was missing some very
> necessary PSIs including PSIs for "topic", "association", and
> "occurrence".  I don't think there is any debate as to whether these
> subjects are also required. So to say that the Dec. 4 deliverable
> was not subject to change is, in my view, an inaccurate statement.

You're right, Eric.  It is inaccurate, because the December 4
deliverable made no such claim.  What the December 4 deliverable
actually claims is much more sensible and appropriate:

  The contents of this XTM 1.0 Core Deliverables document, including
  the XTM 1.0 Document Type Definition (DTD), the XTM 1.0 Published
  Subject Indicators (PSIs), and the XTM 1.0 Conformance clause,
  represent portions of the XTM 1.0 Specification that are not subject
  to any future change that would invalidate any XTM document or XTM
  application that conforms to the syntactic and other constraints
  that the DTD, the PSIs, and the Conformance clause are intended to
  impose in order to guarantee reliable interchange of Web-based topic
  map information in XML.

There's a very big difference between the above guarantee of
dependability, and any claim that "the Dec. 4 deliverable was not
subject to change".  I say again, the latter claim was never made.
Adding more PSIs could not possibly invalidate any existing topic map
or application.  Deleting them, however, would almost certainly
invalidate any applications and topic maps that referenced those PSIs.
This unnecessary wholesale invalidation of any investments in
technology and information assets that depended on the December 4
deliverables is inexcusable and incomprehensible.  It is directly
contrary to the whole purpose and spirit of establishing a standard.

> The statement about the processing model being controlled by ISO is
> entirely inaccurate and I wish to clear this up once and for all. At
> our meeting in Austin, we had in attendance some invited guests
> (approved by the membership). The work on TMQL, on both the ISO and
> XTM sides, is to be based on the XTM processing model, since there
> isn't one for the ISO standard.  During the meeting we were looking
> for requirements and use cases for TMQL that were in addition to the
> requirements that would come from the processing model. At one point
> in the meeting, the question was raised as to the nature of the
> meeting. I stated that it was a joint discussion of TMQL.  Perhaps
> this was an inaccurate statement or had ramifications of which I was
> not aware. At no time did TopicMaps.Org hand control of the
> processing model over to the ISO process, nor did it ever intend to.

If there was no intended dependency of XTM on ISO, then why was the
XTM meeting's precious time being spent to give input to the ISO
process?  Why, especially, when the ISO process turned out not to be
about a query language, but rather about what the meaning of topic map
information really is supposed to be, so that a query language could
then be designed?  Why were we helping the ISO process to move forward
on a processing model when we had yet to discuss the processing model
that was published on December 4, and suppressed on February 17?  If
the XTM group's purpose is to produce a Specification quickly, how
could that goal possibly be served by taking time to give input to the
much slower ISO process?

***

Michel and I are continuing to make investments of our time and energy
in topic maps.  We're publishing our current version of the suppressed
processing model at http://www.topicmaps.net, along with other
materials, and we're supporting and promoting the February 17 version
of the XTM DTD.  It's very good work, after all, and I'm proud to have
been part of the team that produced it.  In my own mind, I include
every Participating Member and every Invited Guest in that team.

However, I am appalled by the behavior of Topicmaps.Org as an
institution.  In its very short life, it has already violated every
kind of integrity that one would reasonably demand of a standards
organization.  Its own records show that it has betrayed its
leadership, its sponsors, its host organization, its participating
members, and every person who has depended on the sanctity and
stability of its only standard.  Come to think of it, maybe its
amazing capacity for betrayal qualifies it for the support of certain
kinds of interests, so it may thrive for many years to come.

It is not qualified for my support, however, and I do not support it.

-Steve

--
Steven R. Newcomb, Consultant
srn@coolheads.com

voice: +1 972 359 8160
fax:   +1 972 359 0270

405 Flagler Court
Allen, Texas 75013-2821 USA

------------------------ Yahoo! Groups Sponsor ---------------------~-~>
Do you have 128-bit SSL encryption server security?
Get VeriSign's FREE Guide, "Securing Your
Web Site for Business." Get it now!
http://us.click.yahoo.com/2cW4jC/c.WCAA/bT0EAA/2n6YlB/TM
---------------------------------------------------------------------_->

To Post a message, send it to:   xtm-wg@eGroups.com

To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC