[topicmapmail] XTM Datatypes [Was: Adding weigths to associations]
Kal Ahmed
kal@techquila.com
Tue, 3 Dec 2002 15:32:05 +0000
Hi Murray,
In many respects I agree with you - extension of XTM to support datatypin=
g=20
causes an increase in complexity - both for users and for implementors.=20
Having a means of interchanging information with data-types is only the s=
tart=20
of the story. Applications would need to be able to recognise and parse s=
uch=20
datatypes (e.g. to ensure that the lexical constraints imposed by the=20
datatype are met); then they should provide some means of manipulating ty=
ped=20
information (e.g. "find all topics where the value of the "rating" occurr=
ence=20
is greater than 4.5"); then they should provide the means of binding the=20
typed information to constructs in the programming language being used to=
=20
access the data.
Although XML Schema is somewhat more complex than an XML DTD, it does at =
least=20
provide the mechanism by which namespaces can be mixed more meaningfully.=
=20
Also, by layering XTM on top of XML Schema, implementers can make use of =
the=20
PSVI or some other post-validation data structure to expose the datatyped=
=20
information.
Of course, the approach you propose is an equally valid one, and it may h=
it=20
the 80/20 point better than a "relaxed" XTM that allows arbitrary XML dat=
a as=20
resourceData. I shall reserve my judgment on that until you get your exam=
ples=20
published.
Cheers,
Kal
On Tuesday 03 December 2002 15:03, you wrote:
> Kal Ahmed wrote:
> > Data-typing could also be addressed by extending XTM 1.0 to allow XM=
L
> > fragments within resourceData elements. In this way, one could use W=
3C
> > XML Schema or your-choice-of-schema-language-with-datatypes to provi=
de
> > occurrence values. In this way, you would be treating topic maps (an=
d
> > specifically XTM interchange syntax) as a "layer" on top of existing
> > datatyping mechanisms, rather than reflecting those mechanisms in to=
pic
> > map terms.
>
> Kal,
>
> I'm strongly against extending XTM, since any extension would
> basically destroy one of the principal reasons for having it:
> namely, a standardized interchange language. And then every
> different approach taken by every different person would have
> to be taken into account. And this is only one possible extension
> among the very many that are possible -- then we end up with
> what's happened to XML: it's too complex to use, if you don't
> ignore most of the plethora of "extension" specs (XML Namespaces,
> XML Base, XML Include, XLink, XSLT, Associating Stylesheets with
> XML (which could transform the document), XPointer, XPath (since
> you need to do them in a transformation), CSS3/CSS Selectors,
> XML Fragments, XML Events, XFrames, XML Schema, etc.). I think
> you get my point. :-)
>
> The idea of mixed namespaces may be considered acceptable to
> many (particularly within the W3C), but absent a rather complex
> schema establishing exactly how the mix occurs, this ups the
> ante on expertise (not too many people can or want to write
> XML Schemas) and processing complexity. You may need an XML
> Schema engine, an RDF Schema engine, XSLT, who knows? By
> comparison, the XTM DTD is quite simple, nicely simple.
>
> I agree that some means of containing content in XTM elements
> and characterizing such content is a good thing. But given that
> a PSI for "boolean" can identify the contents of an element
> within a topic map as well as in an external (ie., non-XTM, but
> addressable) document, I think the PSI quite sufficient.
>
> I'm hopefully going to be able to post some examples of this
> with the PSI set, though I may hold off and just write up a
> detailed description as a white paper of some sort.
>
> Murray
>
> ......................................................................
> Murray Altheim <http://kmi.open.ac.uk/people/murray/>
> Knowledge Media Institute
> The Open University, Milton Keynes, Bucks, MK7 6AA, UK
>
> If you're the first person in a new territory,
> you're likely to get shot at.
> -- ma
--=20
Kal Ahmed, techquila.com
XML and Topic Map Consultancy
e: kal@techquila.com
p: +44 7968 529531
w: www.techquila.com