[topicmapmail] Announcement of XML Schema for ISO 13250 Topic Maps

[Martin Bryan]

Murray

> I'm not sure where you got the idea that there was no way to express
facets
> in XTM syntax.

>From one of the earlier messages on this list stating that XTM did not
support Facets.

> The XTM 1.0 syntax does not have explicit facet syntax, but
> this doesn't stop anyone from expressing facet relationships.

The question is how they generalize them to make them interworkable, which I
happen to believe they need to be.

>We added
> baseName back into occurrence for this reason, at Steve Pepper's request,
> if I remember correctly.

I wondered what that was for - the lack of adequate XTM documentation is a
distinct problem with understanding what these new extensions to the ISO
spec are there for.

>And it's important to note that XTM isn't meant to
> suit absolutely everyone's needs. Every spec has an 80/20 point.
Simplicity
> was judged a very important goal for XTM.

Unfortunately I want the full works, to allow me to develop simple
applications.

>We also didn't want people
> implementing RDF using facet syntax alone - a danger that would have
created
> a second-order, alternative syntax for associations within XTM that might
> damage both understanding and the acceptance of topic maps themselves.

That I can understand! Be assured that I am not going to propose something
that can be used to implement RDF-like applications.
>
> [...]
> > > But OTOH, is XTM 1.0 completely conformant to
> > > ISO 13250, since it let down those features ?
> >
> > Most decidedly not - this is the reason for my rejection of it. (Note my
> > choice of verb - its very deliberate.)
>
> Martin, your message is either deliberately or unintentionally
belligerent,
> and I don't see to what end. If you reject the work that has been done (as
> indicated here and by your storming out of the meeting in Swindon), do you
> want your name removed from the 1.0 Acknowledgements? If you don't want to
> be seen as endorsing the XTM specification, then I'm guessing you don't
want
> your name on it.

My name must not appear in the Acknowledgements of XTM - if it does then the
editors will lay themselves open for legal action.

> I won't repeat what has already been said about teaching angle bracket
syntax.

Teaching not required. To anyone who knows how to debug HTML documents XML
is a doddle.

If I relied on the HTML produced by current applications that "hide the HTML
from users" such as FrontPage or any existing word processor, I would have
something that I could not manage over the decade long period of my work.
Its only because I've kept strict control of the HTML markup used on our
pages that I know I will be able to move up from HTML to XML as soon as I
find wide ranging tools for the application of XML. I'm also thinking
long-term with my limited application of topic maps, as I want to automate
the genreation of this in an manageable and verifiable manner. At present
though, I'll stick to the safe but sure approach of using customized
tagging.
>
> As Nikita has demonstrably shown in his release of various XSLT
stylesheets
> that transform from the various ISO 13250-based DTDs into XTM syntax, the
> specific syntax used is somewhat irrelevant. Given your background, I can
> only guess that you're ignoring this in order to make some point. Calling
> the work on XTM 'insane' insults the efforts of all of us who have put an
> enormous amount of energy into its development, and gives little credit
> or acknowledgement of the work and the specific requirements we operated
> under. XTM 1.0 syntax is distinctly and explicitly an *interchange*
syntax.

When I see a real need to interchange maps I'll change my mind. What is
important is that maps interwork, not that they are interchanged. In my
opinion they can interwork better by adopting a common abstract schema than
they can be adopting a fixed tag set. I know you guys have no faith in XML
Schemas, but when you come back to this listing in two years time you will
understand why I have chosen to take an opposing stance at this stage,
before Topic Maps get cast in unbreakable concrete in the XML world.

> As such, it uses a fixed tag set. To do otherwise would be 'insane' from
> an interoperability standpoint, requiring everyone to first convert to
> another interchange syntax (using something akin to an AF processor) in
> order to merge, exchange, edit, or otherwise process XTM topic maps.
>
> It would seem a *bit* strange to require everyone in the Web world to
begin
> using an AF processor when an interchange syntax suits just fine for most
> applications. Perhaps not yours. But deriding the work of others doesn't
> gain you any friends.

I'm not requiring anyone to do anything, and most definitely not saying
anything about AF processors. I am trying to show people who have looked
seriously at XML Schemas, and particularly at their newest feature,.
abstract elements, why these will be so important for building the next
generations of interworkable applications. I'm using Topic Maps as an ideal
application for the demonstration of this feature, alongside their
application in ebXML.

What I am also trying to point out to people is that XTM is only a stop gap,
and a relatively inefficient one at that. You should be aware that its not
just XTM I am complaining about, but RDF, which is also not efficient enough
for the long-term management of semantics.

One last statement for you all to argue about (not aimed at you  Murray!).
If it is the feeling of the members of this list that the only XML-based
approach to topic maps can be XTM then I suggest you immediately change the
inaccurate name of this mailing list and make it clear it is the XTMmail
list and not a general purpose list for promoting the use of topic maps.

Martin Bryan