atom feed30 messages in org.oasis-open.lists.topicmaps-commentRe: [topicmaps-comment] mergeMap Poin...
FromSent OnAttachments
W. Eliot KimberJun 20, 2002 3:56 pm 
Lars Marius GarsholJun 20, 2002 10:31 pm 
Bernard VatantJun 21, 2002 1:37 am 
Murray AltheimJun 21, 2002 2:01 am 
Lars Marius GarsholJun 21, 2002 2:09 am 
Murray AltheimJun 21, 2002 3:53 am 
Bernard VatantJun 21, 2002 5:17 am 
Rex BrooksJun 21, 2002 5:32 am 
Bernard VatantJun 21, 2002 7:55 am 
Rex BrooksJun 21, 2002 8:36 am 
Thomas B. PassinJun 21, 2002 8:06 pm 
Leonid OtotskyJun 23, 2002 8:44 am 
W. Eliot KimberJun 24, 2002 9:21 am 
Lars Marius GarsholJun 25, 2002 2:14 pm 
W. Eliot KimberJun 25, 2002 2:44 pm 
Lars Marius GarsholJun 25, 2002 3:15 pm 
W. Eliot KimberJun 25, 2002 4:07 pm 
Thomas B. PassinJun 25, 2002 4:57 pm 
Lars Marius GarsholJun 25, 2002 11:32 pm 
Lars Marius GarsholJun 25, 2002 11:34 pm 
Thomas B. PassinJun 26, 2002 3:41 am 
W. Eliot KimberJun 26, 2002 12:17 pm 
Murray AltheimJul 1, 2002 4:31 am 
Lars Marius GarsholJul 2, 2002 11:16 am 
Lars Marius GarsholJul 2, 2002 11:23 am 
Lars Marius GarsholJul 2, 2002 11:31 am 
W. Eliot KimberJul 2, 2002 11:54 am 
Lars Marius GarsholJul 2, 2002 12:05 pm 
W. Eliot KimberJul 2, 2002 12:12 pm 
Lars Marius GarsholJul 2, 2002 12:20 pm 
Subject:Re: [topicmaps-comment] mergeMap Pointing to MoreThanOnetopicMapElement
From:Lars Marius Garshol (lar@garshol.priv.no)
Date:Jul 2, 2002 11:31:35 am
List:org.oasis-open.lists.topicmaps-comment

* Lars Marius Garshol | | This is defined by XPointer: | <URL: http://www.w3.org/TR/xptr/#bare-names >

* W. Eliot Kimber | | Interesting--the referenced section equates bare names to id('foo'). | | This makes sense in that it is the most flexible *if you have DTD- | or schema-aware processing* *and* have a document with a schema or | DTD. But if you don't, then I would think that an XLink processor | would be obligated to fail to resolve a bare name--but I think that | the expectation is that even for DTD-less topic-map documents that a | bare name reference would work (and that's how I've implemented my | mergeMap resolver at the moment).

An XLink processor would, but an XTM processor doesn't have that problem. Of course, what this means is that XLink processors can't really make much of XTM documents, which again means that there isn't really much point in using XLink.

Of course, we knew that all along, and as Murray said, this was just as much a political move and a show of good faith as anything else.

| Of course, if XTM abandoned XLink and defined its own addressing | attribute, it would then be free to both limit the use of XPointer | and define the meaning of bare names unambiguously.

It would, and this is becoming rather desirable. I think the next version of the XTM syntax should ditch XLink. The question is whether the next version of ISO 13250 is going to define something other than XTM 1.0. I for one hope it won't.

(If you haven't already read it, you may find this document useful: <URL: http://www.y12.doe.gov/sgml/sc34/document/0323.htm >.)

| This seems like it might be reasonable change--the syntax hit is | small--really you only need to move the xlink:href attribute into | the XTM name space.

Well, yes and no. It means changing the mechanism by which the arcs in a topic map graph are asserted. It's kind of like changing '<' to be '[' (and '>' to be ']') in XML.

The change is small in one sense, but in another it's clearly not, in the sense that if you use an unsupported version of the syntax (with some software) the result is total breakage. Nothing will work.