Xml parser question

Replies to This Discussion

Permalink Reply by Kristoffer Negendahl on April 16, 2011 at 7:13am

Never mind. I just needed to mess around a little on the forum. A xml-file can of course be seen as a text-file. Save is a little difficult, but streaming is easy. Just right-click the panel, define root, name and set suffix to ".xml".

Permalink Reply by Damien Alomar on April 16, 2011 at 8:06am

Its not what the xml component was designed to do, but saving/creating XML from a stream of data in GH is certainly possible. There are a couple issues that came up when I started thinking about this.  The first is that XML requires that there be one root tag, where GH does not necessarily require their be one trunk to build its tree.  In more GH specific terms, any XML document would always require that a path be {0;....} and there could never be a path like {1;...} or {13;....}.  The fact that GH rarely does this is inconsequential, because its possible, so therefore has to be dealt with somehow.  The first option is to simply have the component throw an error and not write the XML.  That's fine, but in order to use the data you'd have to start remapping or splitting out your tree... not fun.  The second option would be to wrap the data in a root tag so that the XML requirements are met, however this is manipulating the data that you're saving which I don't like. The third option, would be to write each root trunk out into separate files.  The easiest option is 2, but I don't like modifying the data, although it would be possible to put attribute on that root tag to discard it if it was later read back into GH.

 

The second issue is that in order to write comprehensible XML, you'd need to specify the element names along with the values, which has the potential to be very cumbersome.  In your case, you have all your tag names there and are just looking to modify the data that was in those tags, but this is definitely the best case scenario.  If the ability is there to write xml, then that means it can come from anywhere in GH, not just from a previously parsed xml doc.  Inevitably, assuming one would go through the hassle of creating names for all their xml elements, invariably there would be an path that would be missed, so what would you do as the name for that element? Throw an error? write out something else based on the path?  Taking this to the extreme, would it be possible for someone just to supply data with no element names whatsoever? 

 

In thinking about that last question, it would be nice if the GH path could be used for writing out the element names, but unfortunately both curly brackets and semicolons are invalid in element names (ie so <{0;1;0;5}>SomeData</{0;1;0;5}> is invalid because of the {,}, and ; characters. Element names also can't start with a number).  So in order to write out an actual GH path, it would need to be transformed in some manner so that the previous example might look something like this <GhPath_0-1-0-5>SomeData</GhPath_0-1-0-5>

 

There are a bunch of other potential issues as well that would likely leave writing xml from GH in somewhat limited state.  Some of those include enforcing/validating schema and supporting for other xml features(such as CData).

 

Ultimately, when I first wrote the xml parser I wasn't sure what people's needs were going to be in regards to using XML in GH.  Based on the two main issues I outlined above, I chose to leave writing xml out for the time being.  Its not that it can't be done (far from it actually), some decisions just have to be made pertaining to those issues.  It does seam like it would be something useful, so I'll begin to look into adding it, and if you've got some other suggestions or preferences about which solution would be better, then sound off.

 

EDIT:

One thing I should note, all of my comments above pertain to saving xml.  Once you've parsed an xml file, its no longer xml, its just regular data with GH which can be manipulated however you prefer.  It would be entirely possible to to use GH's tree manipulation and list tools to move chunks of xml around, remap xml, etc.

Permalink Reply by Kristoffer Negendahl on April 16, 2011 at 10:11am

I am afraid I have to go with option number one. Splitting and remapping takes a long time and wont reassure the kind of parametric flexibility I really like. But I think your parser tool will make things a lot easier for me. The hard part is to piece everything together again, include the xml version header and format exactly the same way as it was loaded. Well no one said it would be easy.

My primary reason to use xml input-output is to control geometry in GH and out these dynamically to other programs. These programs defines their own mutant-rules of the xml-format - nothing is as standardized as I like it to be. 

 

Thank you Damian.