[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [topicmaps-comment] mergeMap Pointing to More Than OnetopicMapElement
[I've been out of touch for a week, apologies for getting to this just now]
W. Eliot Kimber wrote:
> Bernard Vatant wrote:
>>*Murray Altheim
>>
>>>XTM was designed as an interchange language, not a
>>>catch-all for all possible "legitimate" topic map expressions.
>>>Since there is a simple solution for this within the current
>>>specification, I don't see that opening up the specification
>>>merely because there *may* be reasons to express something in
>>>an alternative (and potentially more problematic) way would be
>>>a benefit for anyone.
>>>
>>I agree with Murray. A DTD is a DTD. You can embed <topicMap> elements, with all their
>>XTM-like children, inside any kind of XML doc, and process it the way you like, but be
>>prepared to pay the price, that is poor interoperability. It can't be considered XTM
>>conformant any more, and you can't ask for XTM processors to make sense of it, nor wait
>>for XTM specification to tell you what to do in such a case.
>
> The XTM 1.0 specification clearly allows documents whose root element is
> not topicMap to be conforming topic map documents *as long as* any
> included topicMap elements do not themselves contain elements from
> another namespace:
>
>>From 4.4, XTM Document Conformance
>
> * All of the syntactic and other constraints specified by the XTM
> 1.0 Specification are honored in each of the <topicMap> elements
> contained in the document. When each <topicMap> element is processed as
> defined and described in Annex F: XTM Processing Requirements, there
> must be no Reportable XTM Errors.
>
> Thus Murray's objection is incorrect--it is explicitly conformant to the
> XTM spec and all conforming XTM processors should handle the case. I
> don't see how interchange can in any way be impaired by allowing
> this--given the no-foreign-elements-within-XTM constraint there can be
> no confusion about what is XTM data and what is not in a given document.
I'm not going to go back to what I wrote (which may be wrong or unclear),
but rather express it as I understand it. According to the XTM 1.0
specification it *is* possible to have an XTM document's root element
be something other than <topicMap>, but only if it's an element in
the XTM namespace. Eg., you are forbidden from having <html> (in the
XHTML namespace) as the root element of an XTM 1.0 document.
Now, having an XTM document's root element as <topicRef> or some other
element may very well be both strange and cause interoperability
problems. Point is (I think) is that XTM was designed as an interchange
format. We had to strike some balance between flexibility and constraint,
and we may have either erred on either side depending on one's ideas of
what XTM documents should be (and the resources one's company might
have in developing complex document importers and exporters). I don't
think XTM benefits from being too flexible, and I certainly admit to
being one of the proponents of the one-namespace rule. XTM is essentially
a simple graph language with scoping. You can do pretty much anything
with it, just like with GXL (hence my idea that translators back and
forth between should be commonly available).
There's been two dangerous fashions in the markup community, one of
overdesigning everything, and also that multiple namespaces are somehow
a Good Thing. In the latter case they are only when the situation
demands, not just when somebody can think of one use case. The recent
discussion of inclusion of XLink in XTM bears this out -- we *could*
have got by without it, but wanted to be considered as "playing well
with others" in the XML community, ie., using "the linking language
for XML" in an XML document type. I sometimes see six or seven
namespaces in a document, with no schema on what their intermixing
means. Yuck. Now I'd be loath to criticize you on architecture (given
my respect for your demonstrable skills), and I think we're generally
in agreement here.
> I am using non-XTM wrapper elements in an experiment I am conducting
> with making it easier to author topic maps directly in XTM syntax by
> using enclosing structures to organize groups of topics into logical
> sets--this has no affect on the interpretation of the topic map (no
> ambiguity or potentially confusing non-topic-map stuff is used *within*
> the scope of the XTM data) but makes it much easier to author a large
> topic map by organizing things in ways that make sense to the author.
> Here is a small example:
>
> topic-set-01.xtm:
>
> <?xml version="1.0"/>
> <topicSet
> xmlns CDATA 'http://isogen.com/xtm/topic_map_control'
> xmlns:xtm CDATA #FIXED 'http://www.topicmaps.org/xtm/1.0/'>
> <title>ISOGEN-Defined Fundamental Topics</title>
[...]
> </topicSet>
>
> I haven't done extensive authoring yet, and I haven't written any
> support functioins for my XML editor, but so far I've found it as easy
> to edit topic maps in this way as it is to edit any other comparable
> syntax for capturing the same sort of information--while one could
> define slightly less verbose syntaxes for some characteristics, the XTM
> syntax isn't that bad for verbosity--certainly no worse than most
> technical documentation DTD's I've worked with. And a few editor
> customizations will make things much easier. The basic hypothesis of
> this experiment is that if you are going to use topic maps as the
> primary representation of your ontological data you might as well author
> in XTM syntax--saves the trouble of defining your own and maintaining
> transforms and in out of it. Anyway, I'm happy with it so far.
Glad to hear of that. I can imagine scenarios where XTM documents
are embedded, in fact I use one myself. When I store an XTM document
in the Xindice native XML database, I wrap it in an XNode wrapper in
order to contain some metadata about the DB record. But I still firmly
believe the decision to prohibit non-XTM content within the XTM root
was a good one. We really tried to keep things as simple as possible,
which is *always* a boon to adoption. cf. RDF, DAML+OIL, etc.
[...mergemap example...]
> As for scope augmentation, the only reasonable answer would be that the
> applied additional scopes apply to all topics in all topic maps merged
> by a given mergeMap. If that's not what I, as the author intend, then I
> can use multiple mergeMaps. There would be no need to complicate
> mergeMap to do anything different (it would be at least as costly as one
> mergeMap per topicMap).
>
> My mergeMap code already enforces the requirement that mergeMap point to
> topicMap elements exclusively.
That's the way I've dealt with it too. Simple is better and less
ambiguous.
Murray
......................................................................
Murray Altheim <http://kmi.open.ac.uk/people/murray/>
Knowledge Media Institute
The Open University, Milton Keynes, Bucks, MK7 6AA, UK
In the evening
The rice leaves in the garden
Rustle in the autumn wind
That blows through my reed hut. -- Minamoto no Tsunenobu
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC