Improve the Flatten To XML File Format

[ngarneski]

The output from flatten from XML is not as elegant as it could be. A big advantage of XML is that it is both human and machine readable, but flatten to XML seems to really neglect the human aspect, and can be a bit akward to process. 

Here is the output from a simple structure using .net serialization:

<?xml version="1.0"?>
<TestConfig xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<VISAaddr>GPIB::07</VISAaddr>
<DBServer>localhost</DBServer>
<CalFolder>C:\Calfiles\</CalFolder>
</TestConfig>

It is nice, short, and human readable. 

Now here is the output of an equivilent structure from flatten from XML:

<?xml version='1.0' standalone='yes' ?>
<LVData xmlns="http://www.ni.com/LVData">
<Version>12.0.1</Version>
<Cluster>
<Name>TestConfig</Name>
<NumElts>3</NumElts>
<Refnum>
<Name>VISAaddr</Name>
<RefKind>VISA</RefKind>
<Val>GPIB::07</Val>
</Refnum>
<String>
<Name>DBServer</Name>
<Val>localhost</Val>
</String>
<Path>
<Name>CalFolder</Name>
<Val>C:\Calfiles</Val>
</Path>
</Cluster>
</LVData>

Its overly long, 21 lines versus 6 from .net. A better way to represent the same information would be something along the lines of:

<?xml version='1.0' standalone='yes' ?>
<LVData xmlns="http://www.ni.com/LVData" version="12.0.1">
<Cluster name="TestConfig" NumElts="3">
<Refnum name="VISAaddr" kind="VISA">GPIB::07</Refnum>
<String name="DBServer">localhost</String>
<Path name="CalFolder">C:\Calfiles</Path>
</Cluster>
</LVData>

Its still not as elegant as the .net result, but I think it looks better than the original. This may seem like a trivial issue with the small XML files I presented, but when you are storing much larger data structures in XML it starts to become a big mess.

[AristosQueue (NI)]

The Flatten To XML node assumes a particular schema. It does not produce code according to a specific schema. You would need a very different node -- one that can parse a schema file and is intimately aware of the details of your data types and the meaning of labels on wires -- to produce the condensed XML that you note from .NET. As I have been putting together my own serialization library ( here ) I've looked into what it would take to produce such schemas and I'm actually of the opinion that LabVIEW *cannot do this*. Odd thing to say, isn't it? But the way I look at it, LabVIEW doesn't know enough about your data to produce XML of an arbitrary schema, and it isn't structured as a language to ever be able to know. In .NET, everything is structured around objects, and you produce a schema for your own data types. But you get stuck if you get a class written by someone else that you want to include in your serialization (anything provided by a central library... think "Waveform").  You have to fill in a lot of higher level information.

Even if we wrote the Flatten To XML That Takes A Schema As Input node, it wouldn't be efficient because you would have to pass in the schema to each call to the primitive that was contributing to the file and each one would individually parse the schema.

What that means is that you're actually asking for a stateful object that can parse the schema once and then absorb data, eventually emitting a string.  That's exactly what my G library is designed to do. As you can see if you pull down the code, this is a very non-trivial operation.

[AristosQueue (NI)]

tl;dr summary: Unless this idea is substantially expounded upon to provide details of how this would work, including all the serialization APIs needed to support it, I am inclined to ask that the R&D team close this idea. The idea as written is to simplistic to ever be implemented as explained in my previous post.

I do consider the serialization problems of LabVIEW to be of primary importance, which is why I've spent so much of my personal development time working on the issue, but this idea isn't the answer, and never can be, IMHO.

[ngarneski]

Aristos- I agree that my idea probably is not an end all be all, and that the same type of serialization that .net has may not be possible, but I don't see how something along the lines of my idea is not possible, or is substantially different other than formatting.

What I proposed was moving the properties, or at least a subset of properties, like "name" and "type" into attribute nodes, while storing the value in the element value (or if only a subset, then the remaining tags in the element value).

I guess, it is less consistant, but it is more readable; and in my opinion more logical.

It could even be specified for either-or, for example:

<Path name="CalFolder"><Val>C:\Calfiles</Val></Path>

or

<Path><Val>C:\Calfiles</Val><Name>CalFolder></Name></Path>

[AristosQueue (NI)]

Ok... I thought you were asking for fields named based on your data, as in the .NET example XML.

I do not know the answer to why our current XML schema looks the way it does. I'll post that question to the developers who made those functions and see if they have a reply.

[Darin.K]

XML has a pretty low bar for signal to noise, yet I agree that even by those modest standards the LV schema is quite bloated.  I use an XSL transform to clean it up considerably for interchange.  Create a few rules, clean up most of the mess and whatever I do not have a rule for is left alone.  Reversal is easy with a second transform.  

[AristosQueue (NI)]

The original developers have long left NI. But the few comments I've found seem to indicate that it has to do with schema validation. Could it be that attributes are optional and tags are not and these are intended as required fields? Does that make sense? I don't know enough of the rules of the XML file format to make any better guess than that.

[Manlon]

If NI were to use a similar idea to the .NET architecture it could simplify the XML:

- Allow for custom schemas

- Allow for xml validation against custom schema

- Allow for schema generation against xml document.

You can always use .NET for this in LabVIEW but integrating this better would save a lot of overhead.

[AristosQueue (NI)]

Manlon: See my previous post for why the custom schemas idea is not viable for these primitives. Custom schemas requires a completely different API and a knowledge of your use of data types that I do not know how LV would ever be able to acquire. LabVIEW users simply don't build everything out of classes which would be needed for schema work, and even if they did, then we would be needing a lot more annotation from the users about what and how to serialize/parse.

The suggestion for use of attributes is good, so far as I can tell. Going beyond that to custom schemas is a non-starter for the basic primitives.