Interesting XML quirk.

[Avi]

Well ... as standard the XML should ignore anything not inside the tags, so not sure what's happening.
It could be that RW is running some checksum/Hash on the file to verify it, but then it would trip on any edit.
As to viewing the characters in Notepad++ [View] [Show Symbol] [Show all characters]
Reformatting XML in Notepad++ - install the XML plug in then do [Pretty print... ] various option there

[kbs666]

Originally Posted by ShadowChemosh

Or worse editor added tab characters. Depending on the encoding you now have carriage return or line feed hex codes In the ASCII file being used to control end of line. It's very possible the RW XML parser is getting tripped up on any or all of those special characters.

In programmer parlance those are all whitespace. Any character code that doesn't actually show as a character on screen is whitespace.

[Acenoid]

Also you could try to strip special characters via regexp outside of the tags... I would need to try it out in order to provide a regexp, but usually thinks like that could be done. I don't know if that can be used then in your script but it should be possible.

http://www.regular-expressions.info/powershell.html

[Acenoid]

maybe just try to replace certain special characters first to see if only tabs / carriage returns are disturbing? Maybe it makes a difference in which codepage you store the file windws/unix/utf ecetera...

[EightBitz]

Originally Posted by Acenoid

maybe just try to replace certain special characters first to see if only tabs / carriage returns are disturbing? Maybe it makes a difference in which codepage you store the file windws/unix/utf ecetera...

I don't know regex ... at all, really. And it's really not that big of a deal ... yet. It may be later, but not right now.

Right now, my biggest issue is why PowerShell keeps reading an empty <contents /> element as a string instead of an XML element. I've tried various suggestions I've found online to do things a different way, but none have worked yet.

[kbs666]

It has to be <contents/> Just as XML is supposed to ignore whitespace outside of tags it does not ignore it inside of tags.

[Farling]

Originally Posted by EightBitz

I tried to see Notepad++ would cause the same issue, but I didn't see the same option to reformat.

What's the name of the other editor you use? The one that was recommended by LWD for the authoring kit?

You need to add the XML plug-in to Notepad++, then you get the "XML Tools" option in the "Plugins" menu. That menu offers various "Pretty Print" options to reformat your text.

I can confirm that RealmWorks doesn't care about blank space. I have been providing it with the nicely indented XML files for a long time without any problems.

Your editor must be making some fundamental error in the XML file for it to fail to load into RW.

[EightBitz]

Originally Posted by kbs666

It has to be <contents/> Just as XML is supposed to ignore whitespace outside of tags it does not ignore it inside of tags.

In my untouched, unedited, full export, it ends with:

</category_global></structure><contents /></export>

There's definitely a space in there. I tried removing it, and it doesn't make a difference.

Either way, when Powershell reads that node, it sees it either as an empty string or a null value, depending on how I read it (dot notation vs. xpath), and it won't let me do anything XML-ish with it.

I'm going to be using categories anyway, so I could just create those categories in the file I'm going to modify, and let that be the end of it, but there's still that part of me that says there has GOT to be a way to do this.

[kbs666]

Either there is something fishy with the editor you're using, seems likely according to Farling, or there is something wrong with the Powershell parser as compared to the XML standard which is also possible.

[EightBitz]

Originally Posted by kbs666

Either there is something fishy with the editor you're using, seems likely according to Farling, or there is something wrong with the Powershell parser as compared to the XML standard which is also possible.

It's the PowerShell parser. Since there is nothing, absolutely nothing in that node, PowerShell doesn't automatically see it as an XML node. It sees it as an empty string.

I just found a way to force it to read it as an object, and it's parsing it correctly now.

As much as I like PowerShell, it does have its quirks. Variable types are dynamic. It doesn't have a clean, clear, reliable way to say, variable x will always be a string, and variable y will always be an integer. It does it on the fly.

In many cases, that's convenient, and in many cases, it's absolutely frustrating.

For anyone who's curious, instead of doing this:

$contents = $RWExportData.export.contents

I did this:

$contents = $RWExportData.export.ChildNodes | Where-Object {$_.name -eq "contents"}

And that did the trick. Problem is that when Powershell saves the edited xml, it saves it as formatted XML. So I may have to find or figure out that regex after all. We'll see how this import goes ...