[sc34wg3] Editorial structure of N0396

[Sam Hunting]

Comments interspersed.

> Patrick Durusau:
>  
> > | Having said all that, let me note that I am in complete agreement
> > | with Steve Pepper that having a data model will encourage more rapid
> > | development of topic map software and the adoption of topic maps
> > | more generally. I am also in complete agreement with Steve Newcomb
> > | that the essence of topic maps is being able to locate all the
> > | information related to a topic from a single location, a concept
> > | that Steve Pepper calls the "colocation objective." (There are other
> > | nuances to those positions but I think that if we have a frank
> > | discussion of the substance, as opposed to scoring procedural
> > | points, we can work those out. This group has some of the brightest
> > | people I have met in 3 separate professional careers and I have no
> > | doubt the ability exists to reach a consensus that will advance
> > | topic maps.)
> > | 
> > | What I think needs to happen is for the various groups that have
> > | formed around particular names need to break up and work on a
> > | consensus for the benefit of topic map generally and not
> > | advance/defend "my (insert part name)." Whether that results in a
> > | multi-part standard or a single part standard, makes little
> > | difference in terms of conformance, for example, which would have to
> > | be consistent across the multi-parts as well as (hopefully) in a
> > | single part standard.
> > 
> > Is this simply a request that we all sit down with blank sheets to
> > redraw the map when we meet in London? If so, that request has already
> > been turned down several times. We can't continue this death march
> > towards the perfect model. I'm sympathetic to the idea of a single
> > model, but I a) don't think we need it and b) despair of us achieving
> > it before the momentum that we have built up is gone, and therefore I
> > think the only way forward has to be to send what we have to Committee
> > Draft status and move on to the real work: TMCL and TMQL.
> > 
> > We've spent two whole years doing *nothing* except fix the bugs of
> > HyTM and XTM. We need to move on.
> 

> I agree with Patrick. A standard is the result of a consensus.

More important than what any person says is what *ISO* says -- and indeed
ISO says exactly this -- that standards are the result of a
consensus-based process.

Moreover, I would argue, FWIW, that they are the result of consensus about
a text as submitted -- not consensus about an imagined text that might one
day be written. (See the original posting on the non-conformance of
N0396, about which all agree.)

N0396 has a note that reads "Rewrite this document in the correct style
for an ISO standard." Until this is done -- and doing this seems to me the
best way to "move on" -- I don't see how it is possible to come to
consensus, since there is no text to come to a consensus about. 

> It's not a power game between defenders of such or such perspective.

In my experience the sort of characterization above is an indulgence best
not engaged in -- and I know, having indulged plenty myself.

> There is no way you can avoid the work it takes to put things together,
> so that they make sense for all players involved in the topic maps
> standard group, and therefore for the impacted industry. 

Well, there may be a way, but it is not clear to me that there is a way to
do this and at the same time conform to the ISO process.

> It's ludicrous to speak of interoperability if the
> group of experts who claim to be the expert group on interoperable
> information and knowledge is not able to make the various parts of 
> the standard fully complement each other and be interoperable. 

Well, the Martian reading this says that the parts of standards aren't
interoperable.... And I'm not sure these chracterizations are useful
either.

> It may or may not take more time, but we'll end up with a stronger 
> standard, that will fit the common interests of involved parties. 
> Every one has to fully understand what the others have done. 
> That's the condition to move forward. Otherwise, it's not a standard,
> it's a joke.

Ditto characterization.

Personally, I think Patrick's thinking on a single standard is useful and
potentially a way forward. (In some ways, it reminds me of the famous
story where Michel and Steve Newcomb were locked into a motel room by
Bryan Bell.. ;-)

My (vague) recollection of the reason for separate documents was length.
We didn't want to publish a 100 page document and then tell people to
split it up for readability. But under the gentle ministrations of members
of the US and UK delegation -- which took place after the cote to go the
separate document route -- N0393 got drastically shorter. Presumably the
same could be done for the combination of N0393 and N0396. 

As for "moving on" -- no one seems to have thought to ask Patrick how long
he thinks it would take to produce a unified text. Patrick?



> Michel
> ===================================
> Michel Biezunski
> Coolheads Consulting
> 402 85th Street #5C
> Brooklyn, New York 11209
> Email:mb@coolheads.com
> Web  :http://www.coolheads.com
> Voice: (718) 921-0901
> ==================================
>  
> 
> 
> _______________________________________________
> sc34wg3 mailing list
> sc34wg3@isotopicmaps.org
> http://www.isotopicmaps.org/mailman/listinfo/sc34wg3
> 

Sam Hunting
eTopicality, Inc.

---------------------------------------------------------------------------
Co-editor:  ISO Reference Model for Topic Maps 
  Topic map consulting and training: www.etopicality.com
Free open source topic map tools:  www.gooseworks.org
  XML Topic Maps: Creating and Using Topic Maps for the Web.
Addison-Wesley, ISBN 0-201-74960-2.
---------------------------------------------------------------------------