[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Round 2: Identifying Data for Interchange

• To: Joshua Allen <joshuaa@m...>
• Subject: RE: Round 2: Identifying Data for Interchange
• From: Ian Graham <igraham@i...>
• Date: Fri, 10 Jan 2003 19:40:07 -0500 (EST)
• Cc: Ian Graham <ian.graham@u...>, "Roger L. Costello" <costello@m...>, xml-dev@l...
• In-reply-to: <4F4182C71C1FDD4BA0937A7EB7B8B4C1074D1BCC@r...>
• Reply-to: Ian Graham <ian.graham@u...>

I guess the question is 'what are you trying to say/send?' My point was
supposed to be that you can say the same thing - say, a position - many
different ways, and all are equally 'good.'

But, if you've got data you've measured then yeah -- send it the way it is
-- just make sure the recipient clearly understands what you're sending.

Have I understood your perspective correctly?

[ My experience here is in exchanging data from physics experiments/
  simulations, which is perhaps not a common example ;-). In that case,
  problems constantly crop up when the experimenters try to 'clean' the 
  data for someone else's use ....  ]

ian


On Tue, 7 Jan 2003, Joshua Allen wrote:

> 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:igraham@i...]
> > Sent: Tuesday, January 07, 2003 4:17 PM
> > To: Roger L. Costello
> > Cc: xml-dev@l...
> > 
> > 
> > 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
> you
> > have a set of fundamental data x, and derived data y, with the
> monotonic
> > relationship
> > 
> > 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
> say
> > which one is 'fundamental'.
> > 
> > Consider your example: which is more fundamental, cartesian
> coordinates
> > (x,y,z) spherical (r, theta, phy) or cylindrical (r, theta, z). The
> answer
> > is -- all of them.
> > 
> > Ian
> > 
> > 
> > -----------------------------------------------------------------
> > 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>
> > 
> 
> 
> -----------------------------------------------------------------
> 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>
> 
> 

• References:
  • RE: Round 2: Identifying Data for Interchange
    • From: "Joshua Allen" <joshuaa@m...>

• Prev by Date: Invitation to a Technology Preview for Sun ONE Integration Server, Secure Trading Agent
• Next by Date: RE: Round 2: Identifying Data for Interchange
• Previous by thread: RE: Round 2: Identifying Data for Interchange
• Next by thread: RE: Round 2: Identifying Data for Interchange
• Index(es):
  • Date
  • Thread