[sc34wg3] Editorial structure of N0396

[Lars Marius Garshol]

* Lars Marius Garshol
|
| So what, exactly, is the problem? Only that the SAM abstract doesn't
| unambiguously spell it out, or something more?

* Patrick Durusau
|
| Something more actually.

Patrick, thank you very much for coming straight out with it.
 
| Yes, N0358 says "multi-part standard," yes it got 8 yes votes.

Which means the committee has officially decided to do it, but that
should it change its mind we can look into how to do that. It may be
cumbersome to do, but if we want we can do it. The point is that we
made the decision once, and if someone wants to change it they have to
come out and say so.
 
| As I tried to point out in the post Sam cites above, what we need is
| a standard, whether mutli-part, single or in some higher plane of
| order, that represents a conherent and consistent view of topic
| maps. Having separate parts, even if "agreed upon" that represent
| varying views, models, conformance requirements and the like, does
| not seem to me to be consistent with either ISO process or a useful
| standard.

Well, let's try to keep the issues apart, here. We decided we wanted a
multi-part standard, and the thinking at the time was that there would
be one part for each of introduction, RM, SAM, XTM, HyTM, and CXTM. We
can decide to change that and move things around, but the issue of
whether we have a multi-part standard or one single standard is
distinct from the issue of whether we have one or two *models*.

Now, in my view the original decision still makes a lot of sense. What
most people will want to read is SAM and XTM, not HyTM, not RM, and
certainly not CXTM. Splitting this into multiple parts makes the
editorial work easier and in my view there's not a whole lot of sense
in having, say, XTM and HyTM in the same document anyway. It also
avoids the situation you have with HyTime where there's a reader's
guide that tells you to start by ripping the document into separate
pieces. If it consists of separate pieces let's write it that way from
the start, and clearly it *does* consist of separate pieces.

Of course, you can still argue that the parts should be: introduction,
model, XTM, HyTM, CXTM without necessarily arguing that it has to be a
single-part standard.

In my view mixing the two issues up just muddles the whole discussion.
 
| That at various times WG3 has agreed upon names for various parts
| does not (to me at any rate) indicate consensus on the content of
| the various named parts. 

There was consensus then. There does appear to be some dissent now,
and I think you'll find that on both sides of the table there are
people who want to change the original plan. I'm still happy with it,
but that's not to say we can't discuss changing it. But then let's
call a spade a spade and say "I want to change the plan!"; there's
nothing criminal about that.

| Yes, that would be at variance with the prior "agreement" but since
| legislatures amend, repeal and revise legislation, courts extend,
| contract and sometimes reverse prior decisions, I see no reason why
| SC34 cannot make the best decisions it can at any point in time. If
| it discovers a better way of stating content, organizing a draft,
| arranging groups to do the work of the committee, it should make new
| decisions that advance the work at hand.

Sure.
 
| Actually I would support Jim's suggestion that we simply drop the
| names and recognize that we are all talking about topic maps and
| that we all want topic maps to progress as rapidly as possible. To
| do that, means that we need to adhere more closely to the ISO
| procedures, not because I am particularly fond of rules for rules
| sake, but because they are designed to achieve consensus on
| substance as opposed to consensus on names which adherents can fill
| with whatever content they see fit.

I agree. What I've learned over the past year or so is precisely this.
 
| 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.

-- 
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
GSM: +47 98 21 55 50                  <URL: http://www.garshol.priv.no >