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] Promotion of Conceptual Model


Regarding widespread adoption and/or rigour and completeness, I'd just like
to echo Ann's point about UML: do not underestimate the number of people who
can read UML diagrams. I've seen no market research, but I suspect MORE
people can read a set of UML class diagrams and understand them than can
read a DTD and understand it. Both need to be augmented by prose, and formal
comments. Our UML diagrams already have formal comments, as does the DTD.
Neither yet has accompanying prose. Both have an author assigned to writing
the accompanying prose.

Conclusion, the Conceptual model is currently at least as "ready" as is the
DTD, and it is also as useful in getting widespread audiences to understand
what we are talking about.

Daniel

-----Original Message-----
From: Steven R. Newcomb [mailto:srn@coolheads.com]
Sent: 17 November 2000 00:55
To: xtm-wg@egroups.com
Subject: Re: [xtm-wg] Promotion of Conceptual Model


> > [Kal Ahmed:]
> > > Anyway, what is wrong with a separate Conceptual Model document ?
> > > It speaks to a different audience and serves a different purpose 
> 
> [Steve Newcomb:] 
> >
> > The stated purpose of Topicmaps.Org is to serve the public interest.
> > Let's actually serve the public interest

[Sam Hunting:]
> It seems the desire is for 1.0 to be as ubiquitous as HTML and as
> exhaustively specified as HyTime. Which one served the public interest
> better? (I'm inclined to answer HTML, though I don't know how this will
> net out over time.)
> 
> Life is full of compromises. I'd be inclined to go with Kal. "At the
> end of the day," only the perception of simplicity leads to adoption,
> and only adoption leads to ubiquity.

The potential benefit to the public from XTM is that the standard
allows everyone to interchange and recombine instances of the kind of
information that XTM is all about.  As far as I know, no other
significant benefit to the public is expected to result from the
existence of the XTM Spec.

The basic purpose of the XTM Spec is to facilitate the public's
ability to interchange "finding" information.  Widespread adoption is
vital, but we must not let the siren song of ubiquity distract our
attention from the primary importance of actually benefitting the
adopters.  We've seen far too much of the "adoption is primary" kind
of standardization logic in recent years, with very mixed results that
are plainly visible everywhere.

Adoption cannot be our primary goal because adoption actually works
*against* the public interest, if adoption does not actually provide
the anticipated benefits to the adopter.  If, when interchange fails,
the finger of blame cannot be pointed at the software whose
nonconforming behavior interfered with interchange, an interchange
standard provides no benefit.  Instead, it causes losses, confusion,
and harm.

Regarding HyTime, let me just say, "Ouch."  I'm certainly not
proposing that XTM repeats the disappointing performance of HyTime in
the arena of public adoption.  I'm not proposing a 400 page XTM Spec,
nor anything like the breadth of scope that HyTime assays (it's really
about a dozen major standards in one monstrously complex
megastandard), nor anything remotely resembling the impenetrability of
HyTime's prose.

Since you bring up HTML, Sam, let me point out that the history of the
implementation and adoption of HTML is a cautionary tale that actually
makes *both* your point and mine very convincingly.  Fortunately for
the public interest, HTML document instances are not usually very
expensive, valuable, or long-lived.  XTM documents, on the other hand,
will frequently be very expensive, valuable, and, we hope, long-lived.
Our primary job is to establish an arena for competition between the
owners/maintainers of XTM documents in their efforts to serve the
public's need to make information findable.  That arena must be
fortified against the depredations of technology vendors.  Either the
XTM Spec will be that fortification, or there will be no arena.

It is not enough to provide conformance criteria only for the syntax
of XTM instances.  It is equally important to provide conformance
criteria for the information carried by XTM instances.  If we don't
have everything we'd like to have in the Spec about the fundamental
nature of XTM information, that's not good, but it would be even worse
to provide nothing at all.  It would be indefensible to withhold what
we have about the Conceptual Model, or to bury it in an annex, simply
because it's not as fully developed as we'd like it to be, or because
we think that it will make some people (such as those who are allergic
to UML) less likely to adopt XTM.  XTM's Conceptual Model is just as
vital for establishing the criteria of conformance as is its DTD.
They must be given equal structural weight in the Spec, and they must
both be normative.  That's all I'm saying.

-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


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

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

-------------------------- eGroups Sponsor -------------------------~-~>
eLerts
It's Easy. It's Fun. Best of All, it's Free!
http://click.egroups.com/1/9699/1/_/337252/_/974456759/
---------------------------------------------------------------------_->

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

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



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


Powered by eList eXpress LLC