Hi everyone,
I just spent a couple of hours trying to implement an XFML importer
for our topic map software suite, and found it pretty easy going. My
main impression is that XFML is pretty much like topic maps with
scope and variant names removed, only one type of association, and
with occurrence strength instead of occurrence types.
Hence building an importer was very easy when I already had a complete
topic map engine to build it on. Merging and resolution of external
references was trivial, and we already had the data model implemented,
which meant I didn't have to do that, either.
I do have some comments, however:
- the spec says to use the application/xfml+xml MIME type for XFML
documents, but this hasn't been registered, so that would be very
bad practice. application/x-xfml+xml would be OK, since that uses
the prefix for unregistered MIME types.
- a better description of how to resolve URIs is needed. For example,
are all URIs in <psi> and <connect> and <page url="..."> supposed
to be resolved relative to <xfml url="..."> or relative to the URL
the XFML document is read from? (My code assumes the former.)
- isn't the facetid attribute on <topic> redundant when a
parentTopicId is specified? What happens if the parent topic
belongs to a different facet? Is that an error? Isn't it cleaner to
require just one of the two attributes to be specified so that
people can't screw this up?
- are processors expected to go out and download XFML maps referred
to with <connect>, or are those references expected to be passive,
and only used when different maps are merged?
- is it required for parentTopicId references to point to topics
already defined above in the document?
- what are the semantics of the <topic> -> <facet> reference? Are the
topics instances of the facets? That is, is a facet a class, of
which the topic is an instance? So "Bogota" is an instance of the
class "City", "Colombia" of "country", and so on. Is that the kind
of semantics implied, or are there different semantics?
The status of my implementation is that I support everything except
<mapInfo> and its contents, <connect>, <xfml language="...">, and
<page strength="...">.
I had to define some PSIs in order to be able to represent the
implicit typing topics used by XFML, however. The reason I didn't do
<mapInfo> is that it would have required a lot more of these, and it's
a bit of work to do that modelling, and not very interesting.
Whether I will do the rest of the implementation and release it
remains to be seen. We have to discuss internally whether it's worth
the effort, basically.
--
Lars Marius Garshol, Ontopian <URL:
http://www.ontopia.net >
GSM: +47 98 21 55 50 <URL:
http://www.garshol.priv.no >