[topicmapmail] occurrence abuse ? Was: [geolang-comment] Firstproposals for ISO 639 and 3166 available

[Kal Ahmed]

On Thursday 22 August 2002 11:29, Lars Marius Garshol wrote:
> * Kal Ahmed
>
> | I can see the need for data-typing on occurrences and I suggest that
> | using the XML Schema datatypes that the database vendor community
> | are so keen on seems like the way to go.
>
> Actually, the database vendors seem annoyed that XML Schemas allow you
> to use datatypes that are incompatible with the SQL datatypes, and
> would like to see XML Schema purged of some of those parts. (This is
> my impression from watching Jonathan Robie on XML-DEV, anyway.) That
> makes a lot of sense to me.
>
> This can be solved by only adopting a subset of the XML Schema
> datatypes, however.
>

Which will make all those people who *do* use the other XML Schema dataty=
pes=20
complain!

> | However, I would say that restricting yourself to typing strings is
> | going to be a bigger turnoff to the database-heads than a little bit
> | of extra markup.
>
> Well, nobody says these things have to be stored as strings. That's
> application-internal.
>

Of course it is - I am talking about the interchange syntax.

> | For example, how would I insert a multi-field record into an
> | occurrence...from a database perspective, I may consider something
> | like an address to be a single entity that I want to store in a
> | single occurrence, not split across multiple occurrences (losing
> | structure on the way). Therefore I would suggest that allowing
> | structured markup inside an occurrence is the most flexible way to
> | proceed.
>
> Oh, I agree with that. This would be the XML datatype, but I think we
> need to keep that separate from the primitive datatypes. Otherwise you
> end up having to nest XQueries in TMQL queries in order to compute the
> total sales per month for each salesdroid, and that wouldn't be at all
> nice.
>

But you would have to do that anyway if the data was structured and stuff=
ed=20
into an "XML" type occurrence. Why is there a need to reinvent all this s=
tuff=20
- I would have thought that it would make much more sense for TMQL to=20
restrict itself to string pattern matching, and then provide a hook for=20
extending with other query syntaxes.

> | What makes me uneasy is that there already is a way to interchange
> | data-typed information and we shouldn't ignore it.
>
> We should definitely not ignore it. The question is whether we should
> adopt all of it, or just parts.

Adopting all of it and nesting it *inside* XTM structures makes a clean=20
division between "knowledge" representation (in XTM) and "information"=20
representation (in strings/XML). The model you propose puts some informat=
ion=20
representation into XTM, and then doesn't even go the whole way but stops=
=20
when something complex (like structured records) comes up...this seems=20
perverse to me.

Cheers,

Kal
--=20
Kal Ahmed, techquila.com
XML and Topic Map Consultancy

e: kal@techquila.com
p: +44 7968 529531
w: www.techquila.com