Result set requirements
Rani Pinchuk <[email protected]> Thu, 19 Feb 2004 10:50:28 +0100
| Newsgroups | gmane.text.xml.xtm.tmql |
|---|---|
| Message-ID | <1077184228.5605.4.camel@mikush2> |
Dear all, It is obvious that there is a trade off between having the result set containing more complex structures and between the simplicity of TMQL. When the syntax of the language provides the ability to get for example the base name of a topic, next to a topic object, it brings up some confusing problems: 1. Different columns in the result set have different type - base name column probably will be of type 'string', while topic columns will be of type 'topic object'. 2. If there is more then one base name for that topic, and the scope was not specified it probably means that a list of base names should be supplied. However, it is not clear in which order such a list should be provided. Finally that list of base names should come next to one topic object (in the same 'row'), so we end up with column of type 'list of strings'. 3. Should the scopes, and the variants of the base name be retrieved with the base names, so actually a structure is retrieved, or should the base names retrieved by themselves? Should we then define different structures for the different sub-structures we have in a topic? For example, when retrieving base name of a topic we get a structure containing base names, their scopes, and their variants. On the other hand, the TMQL could leave the fetching of the actual primitives from a topic object to the programing languages or tools that might use TMQL. In that case the TMQL returns only topic objects (or their ids), and the APIs of different languages will define a way to access the different primitives inside the objects. However, also when TMQL supports retrieving of different primitives such APIs will be needed, unless we restrict TMQL to return only simple textual rows (like in SQL) which is for sure not the intention. So I would like to ask what are the advantages for supplying the result sets in "different types". Thanks Rani -- Rani Pinchuk Software Engineer Space Applications Services Leuvensesteenweg, 325 B-1932 Zaventem Belgium Tel.: + 32 2 721 54 84 Fax.: + 32 2 721 54 44 http://www.spaceapplications.com