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

[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