ER wrote:
> The read and write XML VIs on the palette are definitely oriented
> towards handling LV specific XML files. As you say, the VIs that are
> more useful from a non-LV-centric viewpoint are the subVI's such as
> ParseXMLFragments.vi
>
> I am not familiar with the Match Pattern.vi that you referred to (or
> did you just mean the Match Pattern node on the String palette?).
> Where is it located?
>
> As for writing an XML Parser in G, it is certainly quite a task
> depending on how you approach it. If you want to write a robust
> parser which searches for all tags according to the specification
> (which chars are acceptable, etc), keeps track of the element tree,
> and provides references to each of these nodes, it would be a huge
> task (and G would probably not be the language you would want to use).
> If you ONLY want to parse XML files that you create, then you can
> write much simpler VIs that "cheat" and simply don't enforce most of
> the rules.
My main complaint with XML vis is that they do not output the floats
with proper precision. Extended should have more numbers after the
decimal point than doubles,.. than singles, but they are all formatted
the same, making it useless for me.
The LabVIEW match pattern is somewhat limited in the types of regular
expressions it can match. In the sense of outputting various sub-matches
like the Perl () special characters, it is hobbled and you have to do
all this pre-match and post-match crap. XML does have various shorthand
tags that make element identification more exciting. I have written all
of my own SGML stuff using tags defined like this
indicating that the begin and end tag are always required, So its
limited to tags and content, bfd. Then you have to worry about recursive
use of tags, so you have to parse off one whole unit then parse inside
that, do it like Knuths algebraic calculator example. I have a parser
(not validating) written in LabVIEW that can handle that in my simple SGML.
