FW: [A] XML to Variant?

[Jim K. <ji...@ji...>]

OpenG Developers,

I have updated the Flatten to XML example on OpenG.org by adding an
Unflatten from XML.  "OpenG Unflatten from XML" overcomes two major
limitations of the LabVIEW Native version of "Unflatten from XML"

1) It uses only the XML string as the basis for the output variant data. =
 It
doesn't need a copy of the original data type.
2) It supports data within variants (the native version doesn't)

Anyone want to help work to bring these into the OpenG Toolkit?  Before =
we
can add them to the toolkit we need a test plan to validate that we are
supporting all data types in the schema and that we can handle errors
correctly.

-Jim

-----Original Message-----
From: inf...@pi... [mailto:inf...@pi...] On
Behalf Of Jim Kring
Sent: Tuesday, December 09, 2003 10:20 AM
To: 'Martin Gustafsson'; 'Info-LabVIEW'; 'Dees, Ian'
Subject: RE: [A] XML to Variant?


Martin and Ian,

I got inspired late last night and decided to try and create a pure G
version of "Unflatten from XML" that outputs variant LabVIEW data.  It =
turns
out that it didn't take as long as I thought.  You can download the =
working
example here:

<http://openg.org/tiki/tiki-index.php?page=3DEXAMPLE+-+OpenG+Flatten+to+X=
ML>

But remember, this is just example code.  I'm sure there are a few bugs =
and
maybe some unhandled data types.  If I get enough feedback and folks =
want to
help develop or debug these VIs, I will gladly turn them into a =
supported
library of the OpenG Toolkit.

Cheers,

-Jim


> -----Original Message-----
> From: inf...@pi...
> [mailto:inf...@pi...] On Behalf Of Martin Gustafsson
> Sent: Monday, December 08, 2003 4:34 PM
> To: 'Jim Kring'; 'Info-LabVIEW'
> Subject: Re: [A] XML to Variant?
>=20
>=20
> Jim,
>=20
> Sorry, I misinterpreted you. Yes, I suppose you can say that
> it parses no deeper than the variant, and I do think it is=20
> unfortunate. I would prefer a parser that didn't have a type=20
> input, but instead always put out a variant. This combined=20
> with tools for extracting information about variant data=20
> types would be very useful to me.
>=20
> Best regards
> Martin Gustafsson
>=20
> > Martin,
> >=20
> > Yes, that's basically what I said:
> >=20
> > > > The "Unflatten from XML" function doesn't parse
> > > > the XML string any deeper than the variant,
> > > > meaning that it does continue to convert XML
> > > > data inside the variant.
> >=20
> > Based on your example, the XML string for a Boolean in a Variant=20
> > would look like the following:
> >=20
> > <LvVariant>
> > <Name>Variant</Name>
> > <Boolean>
> > <Name>error in (no error)</Name>
> > <Val>1</Val>
> > </Boolean>
> > </LvVariant>
> >=20
> > But all the variant data gets lost if we convert the above XML=20
> > string to a variant, as shown below:
> >=20
> > <LvVariant>
> > <Name>Variant</Name>
> > </LvVariant>
> >=20
> > This is because "Unflatten from XML" ignores Variant data in the XML =

> > string.
> >=20
> > -Jim
> >=20
> >=20
> > Martin Gustafsson <oct...@te...> said:
> >=20
> > > Ian and Jim,
> > >=20
> > > You cold actually take anything (like a boolean), convert it to=20
> > > variant, flatten to XML, unflatten from XML and get nothing out,=20
> > > regardless of what you wire as "data type" to unflatten.
> > >=20
> > > There is also a reverse phenomenon: If you wire a variant as data=20
> > > type, nothing will come out regardless of what comes in.
> > >=20
> > > Best regards
> > > Martin Gustafsson
> > >=20
> > > > Ian,
> > > >=20
> > > > LabVIEW's native conversion between Variant Data and
> XML is a one
> > > > way, transformation.  The "Unflatten from XML" function doesn't=20
> > > > parse the XML string any deeper than the variant, meaning that=20
> > > > it does continue to convert
> > > > XML data inside the variant.  Maybe the algorithm that=20
> > LabVIEW uses
> > > > to "parse" the XML string is actually traversing the strict data =

> > > > structure (the "type" input) rather than the XML string data=20
> > > > itself.
> > > > To do the later=20
> > > > would require an XML parser, rather than a LabVIEW data=20
> > > > traversal routine. =20
> > > > We (OpenG Folks) thought about creating an "Unflatten from=20
> > > > XML" VI that would=20
> > > > return variant data, since we had already developed a=20
> > pure G version
> > > > of "Flatten to XML", but it was quickly realized that doing the=20
> > > > inverse on variant data would be a larger (but not impossible)=20
> > > > undertaking.
> > > >=20
> > > > You can take a look at the OpenG "Flatten to XML" here:
> > > >=20
> > > > <http://openg.org/tiki/tiki-index.php?page=3DEXAMPLE+-+OpenG+Fla
> > > > tten+to+XML>
> > > >=20
> > > > If you are interested in working on an "Unflatten from
> XML" that
> > > > overcomes the limitations of the LabVIEW primitive, I would be
> > > > more than happy to
> > > > participate.
> > > >=20
> > > > -Jim
> > > >=20
> > > >=20
> > > > "Dees, Ian" <Ian...@an...> said:
> > > >=20
> > > > > Hello, fellow wireworkers.
> > > > >=20
> > > > > I've stumbled onto some interesting behavior in
> LabVIEW 6.1 and
> > > > > was
> > > > > wondering if anyone here has either replicated or even
> > > > worked around
> > > > > this
> > > > > issue:
> > > > >=20
> > > > > 1) In a new, blank VI, drop an error cluster control on
> > the front
> > > > > panel.
> > > > > 2) On the diagram, wire the terminal to a To Variant node.
> > > > > 3) Wire the output of the To Variant node into a Flatten to
> > > > XML node.
> > > > > 4) Wire the output of the flatten node to an Unflatten from
> > > > XML node.
> > > > > 5) Wire the output of the To Variant node into the "type"
> > > > input of the
> > > > > unflatten node.
> > > > > 6) Create an indicator from the unflatten node and run the VI.
> > > > >=20
> > > > > If you probe the data at various points, you can trace the
> > > > information
> > > > > as it becomes a real variant with all the values filled in, a=20
> > > > > valid LabVIEW XML string, and finally a valid but empty
> > variant at the
> > > > > output.  Is there any way to make LabVIEW's Unflatten
> > from XML node
> > > > > pick up all the data from the string?  Is the behavior
> > different in
> > > > > LabVIEW 7?
> > > > >=20
> > > > > Thanks in advance for any advice.
> > > > >=20
> > > > > Sincerely,
> > > > >=20
> > > > > Ian Dees
> > > > > Software Engineer
> > > > > Anritsu
> > > > > 972-783-2120
> > > > >=20
> > > > >=20
> > > >=20
> > > >=20
> > > >=20
> > > > --
> > > >=20
> > > >=20
> > > >=20
> > >=20
> > >=20
> >=20
> >=20
> >=20
> > --
> >=20
> >=20
> >=20
>=20
>=20