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

[Kal Ahmed <kal_ahmed@chrystal.co.uk>]

Perhaps there is a confusion here between the interchange format and the
application formats. It should be possible for both Peter and Jack to have
their own application DTDs, to continue to the same use (flexible &
extensible) authoring and navigation environments and finally to interchange
information by 'downgrading' to the XTM interchange format.

Depending on how the XTM specification is written, it should be possible for
the interchange format to consist of 'template' element definitions which
can be overriden in an application DTD. Consider, for example the XLink use
of xlink:type - so perhaps there could be an xtm:class. So it should be
possible to define a (namespaced) attribute which declares the type of the
element with respect to the XTM interchange format and from there it should
be a straightforward (XSLT) transformation to convert any conforming
application DTD into the interchange format (and this transform in itself
could be considered one means of testing an application DTD for
conformance...)

Cheers,

Kal 

> -----Original Message-----
> From: Jack Park [mailto:jackpark@verticalnet.com]
> Sent: Wednesday, June 28, 2000 6:59 PM
> To: xtm-wg@egroups.com
> Subject: Re: [xtm-wg] XTM Requirements (Was RE: Is this valid per
> HyTime? - topicmapmai l thread)
> 
> 
> 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
> 

------------------------------------------------------------------------
Replace complicated scripts using 14 new HTML tags that work in
current browsers.
Form the Web today - visit:
http://click.egroups.com/1/5561/4/_/337252/_/962273331/
------------------------------------------------------------------------

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

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