XML parsing get node text content and single node when containing < or >

[GarryG]

Please update the XML parsing pallette (specifically the load VI and Node.XML invoke node) to be able to get the actual text contents of a node when it contains ">" or "<".  Currently, if the node text contains ">", the Result XML of the node is displayed, with "&gt;" substituted for ">".  If the node text contains <, the XML document won't even load and throws an error.

To see this behavior, use the LabVIEW example: Query XML Document for a Single Node.vi

Modify any text tag contents to contain either of these characters.

[Darin.K]

Those characters MUST be escaped inside text content, that's life in XML.  If you stick with the parser functions then the escaping/unescaping is almost always transparent for you.

[GarryG]

@Darin.K.  That might be acceptable if the escape &gt; and &lt; were both used consistently, but an error in one case and a substitution (escape) in the other seems kind of strange to me.

More specifcally, this comes about in the XML of the report text for a TestStand For loop step (with result recording turned on).  I'm using LabVIEW to write some custom parsing code for this, and it's auto-generated this way (with < and > in the text, contravening XML convention here: http://www.w3.org/TR/xml/#syntax).  Perhaps this should be taken up with the TestStand IE, but it would be really nice if the LabVIEW VI's would just handle it.

[AristosQueue (NI)]

As far as I can tell, LV's API is handling it correctly in all cases.

A less than symbol is handled differently than a greater than symbol because a greater than symbol leads to a parse error -- a greater than symbol signifies the start of a tag and you can't just have that in the middle of the text. The less than symbol is clearly not a delimiter in that case, however, it should not actually be in the text, so it correctly gets replaced with the escape code that should have been in the original XML code. This is a service to any downstream providers because they will not expect to find any > symbols in the text of a node.

This is all correct behavior.

[Darin.K]

Oh yes, NI is a prime offender when it comes to creating something that is almost-but-not-quite conformant XML.  It makes my head spin thinking about it.  Exporting strings is a prime example.  The result looks a lot like XML, but they blow it.  XML has some serious downsides (bloat, low information content), but it conforms to a strict grammar which allows efficient parsing and transformation, and it is somewhat human readable.  Making something almost,but not quite XML gives you all of the downside while eliminating most of the upside.  Yuk.

I want the XML parser to be "pure" and since it is an external library it probably will be. 

All pseudo-XML generated by LV (or TestStand) needs to be eliminated at the source.  It means developer time is being wasted with custom encoding/decoding routines.

[AristosQueue (NI)]

Darin: This is a complaint about parsing, not generating. And the parser is doing the correct thing.

[Darin.K]

AQ:  That is exactly what I said in my first comment and restated in my second comment:

I want the XML parser to be "pure" and since it is an external library it probably will be.

The problem raised is real and completely valid, the proposed solution not-so-much.

[GarryG]

@Darin,

Thank you for that clarification.  I've made another IE entry under the TestStand IE.  I agree, the XML library should conform to the W3 definition.

The new idea is here:

http://forums.ni.com/t5/NI-TestStand-Idea-Exchange/XML-generated-for-report-text-of-reporting-result...

[Darin.K]

Seeing the new idea, there is a LV Parsing issue!

Quoting from that idea:

<Prop Name='ReportText' Type='String' Flags='0x400000'>
                            <Value><![CDATA[{0} Locals.i = 0; Locals.i < 2; Locals.i += 1]]></Value>
                        </Prop>

The offending characters are inside a CDATA strutcture which is valid!  The LV parser is botching it.  The .NET version has no problem with it.

Your simple example is handled ok, the actual source is valid XML which should be handled.

Probably time for a new idea about updating the LV XML parser, entities would also be nice for example.

(Export to String still seems botched, TestStand folks get props for properly using modern XML)

[GarryG]

haha...

I enjoy the interplay between LabVIEW and TestStand.  Thanks for all of the help narrowing this down.

yes, the LabVIEW VI "Get Node Text Content" doesn't recognize CDATA.  I mis-characterized the original problem (it's not the < and >, it's the CDATA... I'm an XML noob).

@MaryH, please change the status back to something that might get looked at by the Engineers.