[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC