Hi Russel, hi VisAD Listeners,
I'm summarizing the last 3 emails in this one.
Russell Steicke wrote:
>
> On Thu, Dec 13, 2001 at 02:51:14PM +0100, Ugo Taddei wrote:
>
> > I'm about to start some work on an XML Adapter and have considered two
> > formats:
>
> Hello Ugo,
>
> I've written an XML Adapter for a project at the Australian Bureau of
> Meteorology. It was initially fairly specific to that project, but we
> believe it's now general enough for other uses. It will load and save
> one or more Fields or FlatFields in XML format. For a while we have
> been talking about releasing the code for wider use, but have yet to
> receive executive approval for that.
>
> Also, I've done some preliminary work on saving arbitrary VisAD data in
> XML format, ie having all of the VisAD MathType and Data hierarchies
> expressable in XML. The direction I was heading was specific to VisAD,
> (eg using VisAD names for the XML element names), not a general format
> like XSIL.
About a year ago I started a similar adapter. I too tried to keep my
document type definition as close as possible to VisAD. E.g.:
<RealType name="length" unit="SI.meter"/>
or
<Linear1DSet first="0.0" last="10.0" length="3" />
But I endeded up having to introduce some "foreign" objects, which
simplified some other things. For example:
RealType could have an attribute map="XAxis", and RealType.Time could
have an attribute dateFormat="yyyy/MM/dd".
I implemented some sets, but as I reached the functionality we needed, I
stop work on the adapter. By the way, I also used JDOM to read the
files.
>
> If you're interested, I could describe the format we're currently using.
>
Yes, I'd definitely be interested. If you can't release the code, I'd be
happy with the DTD or with a description.
> Russell
>
> > Ugo
>
I agree with Bill when he says VisAD shouldn't have one single XML
format. I'd rather see a VisAD-XML with tags named after VisAD data
classes than, say, an XSIL Adapter for VisAD. Furthermore, having "a"
VisAD XML adapter simplifies the task of converting between different
XML formats by using a XSLT. (But off course, writing an XSLT is extra
work.)
Doug wrote:
> As a
> result, a VMET application IS an XML document. Thus saving the current
> state as an XML file is trivial.
>
I'd also find an excellent thing to have a display's (or application's)
state saved to an XML file. I've seen how the spreadsheet saves its
state and wished my apps did that. However, I find that saving the state
into XML has many advantages.
Perhaps we could also have some of VMET's nicest XML features as part of
VisAD. (I'm thinking of something like DisplayImpl.saveStateToXML():
<Display name="display_1">
<!-- some ideas shamelessly stolen form the spreadsheet's state file
;-) -->
<DisplayGraphMode points="true" texture="false" ...>
<DisplayGraphMode points="true" texture="false" ...>
<DisplayProjection ... here matrix values... >
<Map displayRealType="XAxis" range="-1, 1">
<Map displayRealType="YAxis" range="-2, 3">
</DisplayMaps>
<DisplayData>
<!-- Here the VisAD tags could be (re-)employed -->
</DisplayData>
</Display>
)
Ok, just some ideas. Perhaps too much for the time being. I'd already be
happy with a DTD for VisAD (just for data description).
The bottom line is, an XML adapter is still missing in VisAD. In my
opinion, we should have such an adapter which describes VisAD's data
model as close as possible. Perhaps BOM's adapter does just that. In
which case, I can only hope to see it released...
Thanks for the feedback and for the discussion.
I'm looking forward to seeing BOM's and VMET's work on the net.
Cheers,
Ugo
