Re: [xtm-wg] An XTM test suite

["Steven R. Newcomb" <srn@coolheads.com>]

[Lars Marius Garshol has proposed:]

> - a canonical XTM specification (which describes a
>   single canonical serialization format where all
>   logically equivalent XTM documents will have the
>   same representation)

I think this idea is either a very good idea, or a very
bad one, depending on what you intend, which isn't
entirely clear from your note:


Canonical XTM, type A (I oppose this idea):

  I suspect that what you're proposing is a restricted
  (mainly nonredundant) way of using the current XTM
  syntax, to be called "canonical".  I think this is a
  very bad idea, for many reasons, including the fact
  that that it won't accomplish your goal.  This kind
  of "canonical XTM" simply *can't* demonstrate that
  applications are really understanding the intended
  meaning of XTM syntax.

  This kind of "canonical XTM" would place huge
  emphasis on XTM documents, as if documents are what
  XTM is about.  Interchangeable documents are not now,
  nor have they ever been, what the topic maps paradigm
  is about.  Documents are merely tools for
  interchanging topic map information.  Topic map
  information is what topic maps are about.  What is
  needed is a canonical definition of topic map
  information, rather than a definition of the syntax
  for interchanging topic map documents which is any
  more "canonical" than the one we already have.


Canonical XTM, type B (I like this idea):

  Perhaps you're talking about an entirely new syntax
  whose purpose is to serialize every aspect of the
  application-internal result of an application's
  processing of a <topicMap> element (including, of
  course, the result of processing any <mergeMap>s
  within it, and any <mergeMap>s within the merged
  <topicMap>s, recursively).  Such a serialization is
  not representable by the current XTM syntax, much
  less by any restricted subset of the current XTM
  syntax.  For example, topic namespaces cannot be
  represented as such in the current syntax.  I think
  there is merit in the idea of making an entirely new
  syntax for exporting fully-processed XTM topic maps,
  just to be sure that the topic map documents that
  serve as input (such as your proposed test suite, for
  example) are being understood correctly.

*********************************************************

The fundamental purpose of the design of the topic maps
paradigm is to enhance global knowledge interchange.
The federability of topic map information is not just a
nice feature, it's the key feature.  Topic map
information is not going to be federable if it is not
understood the same way by various applications.  In
the absence of a rigorous definition of exactly how
each syntactic construct, when processed, impacts the
application-internal form -- the topic map information
being compiled by the application as it reads a
<topicMap> element -- federability will suffer.
Different people may wind up using different
applications to produce <topicMap> elements that are,
syntactically speaking, all perfectly conformant.  And
yet these various <topicMap> elements won't be usefully
mergeable by a third application, unless that third
application knows the peculiarities of the source
applications.  And the existence of such peculiarities
in an application can only serve to weaken the
usefulness of the paradigm within that application.

Syntactic equivalences between XTM <topicMap> elements,
as these are discussed in XTM today, are insufficient
to define what topic map information actually is.
Demonstrating the semantic equivalence of certain XTM
inputs with certain XTM outputs will not guarantee that
<topicMap> elements are being properly understood by
the application that's doing the processing.  Indeed,
an application's understanding of the paradigm cannot
be demonstrated by output that takes the form of an XTM
<topicMap> element, no matter how "canonical".

Some historical notes are relevant:

* In 1992, HyTime was published.  It had a syntax for
  powerful hyperlinking (just as XTM now has an even
  more powerful hyperlinking syntax), but a rigorous
  definition of what it meant for things to be
  hyperlinked together was missing.  This lacuna
  created problems that five years of work were
  required to solve, but, since they *had* to be solved
  before hypermedia interchange could really work, the
  problems were ultimately resolved in a formal
  document called the "HyTime Property Set", which
  became an ISO standard in 1997.  It works; conforming
  implementations really interchange hypermedia linking
  information reliably.

* The W3C developed the XML Document Object Model
  (which is really an API, not an object model), based
  on a nodes-and-arcs model called "DOM Tree."
  Unfortunately, the "DOM Tree" was not specified in
  such a way as to allow addressing of XML documents to
  be interchangeable, neutral, and reliable in terms of
  DOM API calls.  The problem appears to be that, given
  arbitrary XML instances, what constitutes a node in
  the nodes-and-arcs of each of their corresponding DOM
  trees is not completely specified.  The problem has
  not yet been fully resolved, but we all hope and
  trust that it will be resolved in the XML Infoset
  work.  In the meantime, we have an XML (meta) syntax,
  and a DOM (meta) syntax that are not rigorously
  synchronized, with the result that the same DOM calls
  to the same components of the same XML documents can
  return different information depending on which DOM
  implementation you happen to be using.

* When XTM was formed, there was consensus that
  rigorous correspondence between XTM syntax and the
  topic map information that should be derived from XTM
  documents was necessary if we are going to make our
  contribution to global knowledge interchange.  We
  don't have that rigorous specification yet.  I think
  it's absolutely essential.  The syntax is only half
  of the job.

> So, is there any interest for an effort like this?
> Like I said, Ontopia will have to do this anyway, the
> question is just whether the community will share the
> effort and benefits or not.

I'm interested in making Canonical XTM, Type B (as
described above).

I'm not interested in making Canonical XTM, Type A.  In
fact, I will actively oppose the idea of making a
restricted version or of the XTM interchange syntax, or
a restricted convention-of-use of the XTM interchange
syntax.  I regard the existence of such a thing as
inimical to the cause of global knowledge interchange.
It's contrary to the whole idea that the topic maps
paradigm makes it possible to derive new, highly
ordered, fully federated topical structures from
arbitrary sets of independently produced and maintained
<topicMap>s.  My nightmare is that we will create this
"canonical" monster that will give rise to quick and
dirty applications that can accept only "canonical" XTM
documents, which, oh, by the way, can't have any
<mergeMap> elements in them, because that might cause
there to be two <topic> elements that have the same
subject, which would be redundant and non-canonical.
In itself, that's not so bad, but what's really bad is
that "canonical" XTM documents, because they can't have
any <mergeMap> elements in them, will not use the topic
maps of others.  Thus we wind up with a strong
disincentive, on the part of the actual creators of
topic maps, to federate knowledge.  If you care about
global knowledge interchange, as I do, this is exactly
the wrong thing to do!

-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 ---------------------~-~>
eGroups is now Yahoo! Groups
Click here for more details
http://click.egroups.com/1/11231/0/_/337252/_/982293519/
---------------------------------------------------------------------_->

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

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