Lists Home |
Date Index |
I get very nervous about saying "just derive it" about any data. If the
data is important, it shouldn't be derived. If it's not important,
there is no point even talking about it or having a schema for it -- let
each user "derive" how they want.
I know it seems common sense to say "we only store Fahrenheit, since we
can 'derive' Centigrade", but many an IT manager has been burned badly
by that sort of common sense. There are very few exceptions to this
rule. Data isn't math.
> -----Original Message-----
> From: Ian Graham [mailto:email@example.com]
> Sent: Tuesday, January 07, 2003 4:17 PM
> To: Roger L. Costello
> Cc: firstname.lastname@example.org
> On Tue, 7 Jan 2003, Roger L. Costello wrote:
> > Now let's get back to the hard issues:
> > - should there be 2 schemas, one for fundamental data and one
> > for derived data? I will argue that there should only be
> > one schema - the fundamental data schema. Derived data is
> > transient and should not have its own schema. What do you
> > think?
> > - at what point does sharing of fundamental data become a
> > Service of derived data?
> I honestly don't think you can always make such a distinction. SUppose
> have a set of fundamental data x, and derived data y, with the
> y = f(x),
> Then a simple transformation can make y fundamental, and x derived
> x = g(y) (g = the inverse function to f)
> So it would seem you need something to define the semantics of either
> data model (so that interpretation is consistent), but can't really
> which one is 'fundamental'.
> Consider your example: which is more fundamental, cartesian
> (x,y,z) spherical (r, theta, phy) or cylindrical (r, theta, z). The
> is -- all of them.
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
> The list archives are at http://lists.xml.org/archives/xml-dev/
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>