[tmql-wg] Proposed requirements: Operations on primitive types

Robert Barta rho@bigpond.net.au
Wed, 23 Jul 2003 06:02:38 +1000

On Tue, Jul 22, 2003 at 04:48:58PM +0100, Chris Angus wrote:
> I guess that the reason that I brought it up was that if anything is to
> be done around typed resources it would be difficult to ignore the
> existence of the class-instance mechanism.  The problem, as I see it,
> would be making the connection between a TM class and a specific
> primitive data type - it would not seem that appropriate for a query
> language to be making the necessary assertion and there are currently no
> PSI's for them.


That's a very good point.

I agree with Lars that typing actually belongs to the TMCL problem
domain.  This makes sense as things like integer, float, date... all
form their own 'ontology'. What would be nice if we could keep the
languages themselves free of these 'basic types' and add them via
ontologies (just to use some notation):

#-- Package Numbers from Vendor X ------------------------------------------

# this ontology defines primitive types and functions on them

integer (urn:x-topicmaps:class)                   # this means integer is a type
bn: integer
in: positive, negative numbers, limitations

float (urn:x-topicmaps:class)                     # so is float

boolean function is_integer (string $s) returns { # implementation

boolean function is_float (string $s) returns {

(urn:x-topicmaps:class-subclass)                  # now we know that if the test
subtype: integer                                  # is_integer worked, then also is_float
supertype: float                                  # would return true


So if you validate a map M and it contains all sorts of numbers, a
constraint C without knowledge about these number could check the
structure itself.

Another constraint C' enriched by the above
ontology, C' + Numbers can check also the integers and floats.
In the constraint one would then write

rho-bank-account (bank-account)
bn: stop weeping now
in (money): ?is_float()

That would check the inline (resourceData) for a float.

If someone does not care about the numbers, just ignore it. If someone
has very specific needs for types (XML with a particular validation
mechanism, special date formats, ...), he just builds a new ontology
and merges it with the constraints, the maps or the queries.

Loose thoughts at 6:00 without coffee.