[
Lists Home |
Date Index |
Thread Index
]
Hi Tedd,
tedd wrote:
> So, the bottom line here, is that using <data> 1234.5678 </data> for
> thousands of samples is perfectly legal, accepted, recommended, and an
> efficient method of storing and retrieving data.
As was pointed out before, there are a numerous ways of representing
your data in XML which are all perfectly legal. When you think about
representing you data in XML, you should first consider what it is, that
you want to achive by this step. I bet it's not just "hey, everybody
seems to do XML, so let's do it too"
I'll try to guess around a bit, to give you an idea, what I'm trying to
get to.
a) Interoperability is a commen benefit adopters of XML representations
are seeking. Since XML establishes a representation of your data
structure that every decent system can understand and process, since
almost everything comes with an XML parser today, and the concepts
behind those infrastructures are well understood among developers. Which
means, that once a schema is aggreed upon, all pareties have an easy way
of communicating.
b) leverage existing technology as in b.1) you want to use a 3rd party
application which expects data to be in some XML format or (more likley)
b.2) use a transformation technology as XSLT or XQuery in order tp
'render' different representations of your data
c) xml is easier to read :)
From a quick glance at the LAS sepecification an xml representation of
that format might well make sense an propably look something like
<las:log xmlns:las="http://www.cwls.org/las3";>
<las:version>3.0</las:version>
<las:well-section>
<las:start las:unit="M">1660.1250</las:start>
<las:end las:unit="M">1660.8750</las:stop>
<las:step las:unit="M">.01250</las:step>
<las:null>-99925</las:null>
<las:company>ANY OIL COMPANY INC.</las:company>
<las:well>ANY ET AL 01-02-03-04</las:well>
...
<las:parameter-section>
...
</las:log>
One could then for example use an XQuery engine, to get the names of all
wells owned by a specific company from a set of such xml files, or
render a file to html of xsl-fo and then PDF to get some nice printout.
Or do a transformation that does some unit conversion etc... All this
could be done with more or less standard tools and declarative
definition of processing/transformation rules.
Also the readability of the format would benefit.
for all the data arrays, it seems like the list types that are defined
by the various schema languages (e.g. relax-ng or w3c's xsd) are the way
to go, since there would be no benefit in encapsulating the individual
values in their own elements. It might make sense, if you want to do
some transformation to svg for visualization of your data, but since svg
uses list constructs too, that might not be neccessary (any SVG experts?)
HTH,
~Lars
--
Lars Oppermann <lars.oppermann@sun.com> Sun Microsystems
Software Engineer - StarOffice Sachsenfeld 4
Phone: +49 40 23646 959 D-20097 Hamburg
Fax: +49 40 23646 550 http://www.sun.com/staroffice
|
