I think this is a two-level process. First is recognising that the surface
rules from other domains don't apply. Second is identifying common patterns
and meta-rules behind both domains. Learning something new gives you
insight into old areas of expertise.
>In my opinion, you must THROW OUT the notion of type to make progress on
>this front. Of course, you can then re-introduce the notion of type at
>some higher level.
The approach I've adopted for our database mapping is
- elements map to fields, thus element names being the same in different
contexts is indicative of possibly similar content but not a guarantee. eg:
Name would have similar semantics inside Person and Class.
- data types come from attributes or DTD/some other schemata. Name would be
of character type initially. If the data type is a subclass of character
data, and Name in both contexts ends up being the same subclass then it is
vastly more likely that the data serves the same purpose in those contexts.
This is not new or distorted for an XML perspective. Data typing of fields
in databases indicates only some of the semantics of the field. The rest
are context-dependent. This is true whether using object-oriented or
relational databases.
Andy Dent BSc MACS AACM, Software Designer, A.D. Software, Western Australia
OOFILE - Database, Reports, Graphs, GUI for c++ on Mac, Unix & Windows
PP2MFC - PowerPlant->MFC portability
http://www.highway1.com.au/adsoftware/crossplatform.html