OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

topicmaps-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [xtm-wg] DTD XLink thought


Graham Moore wrote:
> 
> Could Association be treated as an exteneded link with role being xlink
> locators. I think this is a useful way of seeing things.

Graham,

I think you're very correct in the understanding of this, but after
spending many hours with XLink I've found that there's no way to actually
XLink extended links. There are many reasons why only simple links
can be used, and I'd be happy to discuss this with you at length, but
I'm sure the time for both of us is very limited. I'd hoped to do this 
at the Dallas meeting, but time was short. I wrote up several sample topic
maps for myself and spent probably twelve hours on Xlink syntax, ending in
frustration.

First good reason: XLink elements cannot be deeper than child level
or they lose their definition in XLink. No deeper containment is
defined. Secondly, arcs are only valid within their extended link 
container, yet arc elements must be children, not descendants, ie., 
they can't be nested even as deep as grandchild. I even found that 
xlink:title doesn't work for us for the same reasons (eg., the 
<baseNameString> element is a grandchild of <topic>, so <topic> wouldn't
even see it). And you can't have xlink:extended inside of xlink:extended
for a similar reason: there's no semantic defined, so XLink engines 
wouldn't provide us what we need here either. *sigh*

All of my attempts at syntax for this in XTM failed to be compatible 
with both XTM requirements and XLink. I spent some time with Eve Maler
(an editor of XLink) on this, and I think simple links are all we can use.
Sadly. I'd really hoped to promote XLink's more complicated structures,
but neither Eve or I could come up with something that worked. We ended
up with a much easier syntax pedagogically, in that we only have three
kinds of links: <resourceref> to point to resources, <topicRef> to point
to <topic> elements, <subjectRef> to point to things that are the subject
of a topic (referent="isSubject" in our older syntax), and finally
<subjectDescRef> to point to things that describe a topic (the 
referent="describesSubject" of olde). 

We still have the legacy of <mergeMap>'s old syntax, which should 
probably be a container for <resourceRef>, but I'm okay with <mergeMap>
itself being a link since it's probably fairly rare to use it for 90% 
of people using topic maps.

Murray

...........................................................................
Murray Altheim, SGML/XML Grease Monkey     <mailto:altheim&#64;eng.sun.com>
XML Technology Center
Sun Microsystems, 1601 Willow Rd., MS UMPK17-102, Menlo Park, CA 94025

      In the evening
      The rice leaves in the garden
      Rustle in the autumn wind
      That blows through my reed hut.  -- Minamoto no Tsunenobu

-------------------------- eGroups Sponsor -------------------------~-~>
eGroups eLerts
It's Easy. It's Fun. Best of All, it's Free!
http://click.egroups.com/1/9698/1/_/337252/_/974425783/
---------------------------------------------------------------------_->

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