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] XLink use in XTM


itstime wrote:
> 
> XLink 1.0 is now a W3C recommendation. I was wondering why extended XLinks
> are not currently used in Topic Maps. Has the topic of the possible benefit
> of using the more versatile extended XLink type been considered? To date 
> only the simple type of XLink is utilized.
> I thought this is a good time to bring up the topic while XTM is still 
> being ironed out.

XTM is not being ironed out. The group of people involved in creating it
fulfilled their charter and delivered the spec to the public last December,
then approved it early this year. The DTD is considered stable enough that
it is being submitted to ISO to become part of a corrigendum (I believe)
to ISO 13250. The further work necessary is application development, and
work on the processing model, templating mechanism, query language, etc.

I spent a great deal of time analysing XLink while we were developing
XTM's syntax. I talked with Eve Maler and other people on the W3C linking
WG and worked out various possible approaches.

The reason why XTM only uses XLink's simple links is twofold. First, the
kinds of links necessary are really only simple links. For XTM to have
used extended or arc links, the entire linking model would have become
more complicated that was necessary. We wouldn't have really bought much
with more than we have.

Most importantly, if you read more carefully in the XLink Recommendation,
you'll find that in order for us to use extended (or anything beyond
simple, really), the link components must be direct child elements. There's
no good way (if you look at the structure of XTM) to have every link element
inside a <topic> element be a direct child. We have sometimes four or five
element deep nesting. This precludes our use of extended links. Sadly, 
really.

>From XLink 1.0 Recommendation, Section 5.1 [XLink]:

   "Subelements of the simple or extended type anywhere inside a parent
    extended-type element have no XLink-specified meaning. Subelements 
    of the locator, arc, or resource type that are not direct children
    of an extended-type element have no XLink-specified meaning."

In English, this means you can't nest extended links, and all the link
components must be direct child elements. Those of us who've been working
with this syntax have been very happy with it. At least those I know about.
It would have been nice to have been able to use more facilities of XLink,
but their design didn't allow it. I think XTM is sufficiently functional
without a more complex link structure. Most of the complexity is not
lexical, but in the hands of the author, which is IMO as it should be.

Murray

[XLink] Section 5.1: http://www.w3.org/TR/xlink/#extended-link
...........................................................................
Murray Altheim                         <mailto:murray.altheim&#x40;sun.com>
XML Technology Center
Sun Microsystems, Inc., MS MPK17-102, 1601 Willow Rd., 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

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

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

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 




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


Powered by eList eXpress LLC