Re: [xtm-wg] XTM Requirements (Was RE: Is this valid per HyTime? - topicmapmai l thread)

["Jack Park" <jackpark@verticalnet.com>]

Hi Peter,

Help me out here. What means "domain specific"?  And, where does 'spatial'
come from?  And, what are the core purposes of a topic map?  Guess I'm
missing something here. I always thought that a topic map was about
navagating an information space. I am trying to help standardize just one of
the many presentation mechanisms for TMs.  Why should that be pluggable?

Jack

From: Peter Jones <peterj@wrox.com>
> Hi Jack,
>
> I guess what I want is that the functionality that you require should be
> 'pluggable', since it is domain specific, IMHO.
> It does not seem to me to be crucial to the core purposes of a topic map.
>
> What if i want to merge one of your 'spatial' topic maps with an ISO 13250
> one?
> Why would I want to have to deal with all the overhead of parsing an extra
> six attributes (not #REQUIRED => #IMPLIED | known defaults, which is as
good
> as XML gets here), when I could just set my PJsTMSAXParser to ignore
> namespaced attributes instead, or not validate against certain public
domain
> parameter entity includes?
>
> Give me pluggable.
>
> best
> Peter
>
> -----Original Message-----
> From: Jack Park [mailto:jackpark@verticalnet.com]
> Sent: 28 June 2000 17:09
> To: xtm-wg@egroups.com
> Subject: Re: [xtm-wg] XTM Requirements (Was RE: Is this valid per
> HyTime? - topicmapmai l thread)
>
>
> Comments below.
> From: Sam Hunting <sam_hunting@yahoo.com>
>
> > [ Peter Jones writes]
> > >
> > > Your x,y,z attributes look to me like something I would only want if
> > > I chose to look at a topic map in that way: application specific.
> > > I.e. something that you could quite easily add in the form
> > >
> > > jackpark:x="120" jackpark:y="234" jackpark:z="456"
> > >
> > > so that they would be of use to you, but could be ignored by
> > > conforming processors.
> >
> > Actually, Jack proposed attribute syntax:
> >
> >     <topic x="120">
> >
> > *not* namespace syntax ("jackpark:x:).
> >
> > Before advocating namespace syntax for XTM please, if you are not
> > already doing so, follow the current namespace discussions at W3C.
> > http://www.xml.com/pub/2000/05/17/deviant.html is a good starting
> > point.
> >
> > S.
> >
> > P.S. I'm torn between  (a) rejecting them entirely, as a conceptual
> > morass, and (b) trying to hijack them to put them to good use. Frankly,
> > in practice namespaces pollute the very notion of generic identifier
> > with processing information, I'm inclined to alternative (a). Lie down
> > with dogs, get up with fleas.
>
> I did not conceive of any namespace in the specification I proposed. And,
my
> original thinking was that the values would not, in any way, be #REQUIRED.
> And, in particular, a "jackpark" namespace has really no place in this
> discussion. To narrow the focus of my proposal to that of a specific
> instance (me), is, IMHO, to miss the whole point I believe I was trying to
> make.
>
> As it turns out, I am very much involved in the development of TMs from
the
> visual aspect. I am sure Benedicte Le Grand will have much to say about
this
> as time goes on, but my view, at present, is simply to bring TMs into the
> classroom. To do so, I must somehow make TMs appear visually in the same
way
> that Concept Maps are presented and constructed in classrooms around the
> world today.  I have stated before that CMs are something akin to TMs on
> steroids.  Perhaps that is a bit misleading. In any case, I believe that
we
> have the opportunity to take TMs all the way to the bottom of K-12
> curriculae if we include the ability to model the visual aspect as well as
> the structural and (eventually) semantic aspects of some universe.
>
> Oh, and BTW: I forgot to mention the dimensions of the topic visual.
Thus,
> I am now proposing something along these lines:
>     <topic> name="sometopic" ...other stuff.... x="10" y="20 z=""
width="20"
> height="12" depth="" >
>
> If the values are not declared, the dtd won't cause the parser to holler.
>
> My personal vision is that an API can fall out of the final specification
> such that implementations of all kinds (applications) can be constructed
and
> still interoperate. Thus, I don not see the application-specific issue in
> the same way as as Peter does. My opinion, FWIW, is that the addition of
> graphical attributes to our topics does not make the specification any
less
> clean than it would otherwise be.
>
> Thus, I respectfully maintain my submission of these extensions to the
> standard.
>
> Jack Park
>
>
> ------------------------------------------------------------------------
> Replace complicated scripts using 14 new HTML tags that work in
> current browsers.
> Form the Web today - visit:
> http://click.egroups.com/1/5769/4/_/337252/_/962208428/
> ------------------------------------------------------------------------
>
> To Post a message, send it to:   xtm-wg@eGroups.com
>
> To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com
>
> ------------------------------------------------------------------------
> Create professional forms and interactive web pages in less time
> with Mozquito(tm) technology.
> Form the Web today - visit:
> http://click.egroups.com/1/5770/4/_/337252/_/962210793/
> ------------------------------------------------------------------------
>
> To Post a message, send it to:   xtm-wg@eGroups.com
>
> To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com


------------------------------------------------------------------------
Create professional forms and interactive web pages in less time 
with Mozquito(tm) technology.
Form the Web today - visit:
http://click.egroups.com/1/5562/4/_/337252/_/962215250/
------------------------------------------------------------------------

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

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