RE: [xtm-wg] Promotion of Conceptual Model

[Daniel Rivers-Moore <daniel.rivers-moore@rivcom.com>]

"our particular use of UML" ... "our particular use of ELEMENT and ATTLIST
declarations" ...

The "meaning" of a DTD declaration is as ambiguous as the "meaning" of a UML
diagram. The "syntactic conventions" of DTD syntax and those of UML diagrams
are both being conformed to. We're not re-explaining DTD syntax. We don't
need to re-explain UML syntax either. What we do need to do is give
sufficient context and explanation (and worked examples) to help convey what
the declarations and the diagrams are expressing.

I think *both* the DTD *and* the UML diagrams should be in annexes (in their
complete, formal wholeness, carrying with them only the formal comments).
But before you get to the annexes, you should have been walked through the
entire meaning  of Topic Maps, with appropriate illustrations to help get
each construct across. These illustrations will be relevant ELEMENT and
ATTLIST productions, relevant UML drawing fragments, relevant examples and
relevant explanatory prose. Most XML specifications talk through the ideas,
with formal productions interspersed as needed, and then re-states the
complete declaration set as an annex. We can do the same, bringing in the
UML diagrams alongside the related DTD fragments as we go through. This will
provide the completeness Murray describes, as well as pointing out the
correspondences and mappings between the two formalisms.

Daniel

-----Original Message-----
From: Murray Altheim [mailto:murray.altheim@eng.sun.com]
Sent: 17 November 2000 00:15
To: xtm-wg@egroups.com
Subject: Re: [xtm-wg] Promotion of Conceptual Model


"Steven R. Newcomb" wrote:
[...]
> 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.

And I think we generally agree in what we want, but not in how to approach
getting that into the specification. I've been an advocate of the AG members
working together (there is no syntax/model distinction any more, remember?)
on writing *into* the prose of the specification the essentials of the 
topic map model. You seem to think there is value in it being some sort
of special entity that can be pointed to inside the spec, as if it were
pages 13-17 and could be printed out and pointed to as "The Conceptual
Model". The specification is and must be a combination of the model and
syntax. The current online spec spends its first half discussing the 
various components of topic maps: topics, associations, etc. The reason
I thought the UML should live in an Annex was because absent Eliot's
description of our particular UML usage, there's nothing normative about
a UML diagram. It's very ambiguous. Do we want Eliot's UML description
to be part of the spec too?

If the model (which in Paris I understood to be three things: an abstract
model, a processing model and a syntax model) is to exist in prose that
people can actually read, understand, implement and author via, then what
*else* could possibly be in that first half of the spec? Isn't that where
the explanations of the "is-ness" of topic maps (ie., the abstract model),
how things like scoping work (ie., the processing model), and finally how
this all maps into the XML syntax (ie., the syntax model) live? I can't 
even conceive of any other way to do this, other than to create something
called "Section n: The Conceptual Model" that contains a bunch of UML 
diagrams with some prose to first explain our particular use of UML
followed by how our abstract model maps into processing and syntax. 

This latter idea is both frustrating and frightening, in that unless 
there is a harmony of both language and understanding the specification
will be expressing two complete ideas, with no formal or informal (ie.,
demonstrable) mapping between them. Worse yet, if there are unresolved
conflicts in either language or concept between the model and the syntax
the spec will surely be confusing to our audience. I'm not entirely
sure what our priorities are here, but certainly things that confuse
people must be altered prior to being incorporated into the 1.0 spec,
whether they are descriptions of model or syntax. And disagreements
between model and syntax are really going to bite us in the ass (pardon
my French), even if those disagreements are only in language and not
concept.

Murray

...........................................................................
Murray Altheim, SGML/XML Grease Monkey     <mailto:altheim&#64;eng.sun.com>
XML Technology Center
Sun Microsystems, 1601 Willow Rd., MS UMPK17-102, Menlo Park, CA 94025

      In the evening
      The rice leaves in the garden
      Rustle in the autumn wind
      That blows through my reed hut.  -- Minamoto no Tsunenobu


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 -------------------------~-~>
Create your business web site your way now at Bigstep.com.
It's the fast, easy way to get online, to promote your business,
and to sell your products and services. Try Bigstep.com now.
http://click.egroups.com/1/9183/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