Relationship between Q and STC - Frames & Mapping
mchill at dial.pipex.com
Tue May 11 03:58:02 PDT 2004
Brian Thomas wrote:
> I think there is a strong need for some way to create Q's
> that get their values from mappings (mappings are particularly nice for
> compact description of large quantities like axes). But you don't want to
> just allow the user of the Q to change (or mix!) how the values are created
> in any given Q (it would be a nightmare to implement..). This is why I suggested the
> constructor as a likely place (once made, how Q interoperates with its values
> is set).
> I'd also favor having a boolean method to determine the nature of how
> the values are generated in a Q also. This is nice because you can't (shouldn't) do
> "q.setValue(Obj, Location);" method call on a Q that has a mapping
> behind it. The method thus allows the user to pre-determine whether its
> OK to make the setValue call rather than having to always catch an error.
I don't think this is a sufficient check; if values shouldn't be set
then we shouldn't have a method to do so... If we can map values out
can we normally expect to reverse them back in? But then I'm not in
favour of changing values anyway!
> It's also important to reinforce that the current mapping prescription is
> for *values* (V-mappings if you will).
I understand (now) this is the intention but not why. If you have a set
of values in a frame then the values should be in that Frame; if the
values need to be mapped to something in order to appear in that frame
then that should be done when the Quantity is created. If the values
have some use in their 'raw' form, ie presumably in some other Frame,
then they should be presented with that other Frame. I'm just going to
read Dave's examples though...
> There are *no* mappings for
> generation of Q's (this is a point that took me some time to grok). There may
> be a need for mapping Q's into other Q's (I think so, particularly for use in
> tandem with UCD3/ontologies) but currently that isn't the case, and there
> are no plans at this time to make Q-mapping interface/serialization.
07901 55 24 66
More information about the dm