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


[Steven R. Newcomb]
> I believe that while it will obviously be better to have a good prose
> explanation of the Conceptual Model, the UML slides alone will serve
> the primary purpose, in a pinch.

I agree, but I also wanted to remind that
Conceptual Model UML does not correspond directly to the Syntax DTD.
(And this is what people will expect if UML model accompanies DTD)
For this reason there should definitely be a
chapter explaining what the conceptual model is and how and why it is
different from Syntax.
This chapter should be in big red letters too :-)
Otherwise people will skip it as they skip "boring" license agreements :-)
and start asking "why" questions.

Nikita.

----- Original Message -----
From: Daniel Rivers-Moore <daniel.rivers-moore@rivcom.com>
To: <xtm-wg@egroups.com>
Sent: Friday, November 17, 2000 5:23 AM
Subject: RE: [xtm-wg] Promotion of Conceptual Model


> "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
>





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

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