Have you ever faced an error like this?
<XOGOutput xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="../xsd/status.xsd">
<Statistics failureRecords="0" insertedRecords="0"
<Description>[Error] :0:0: uncompleted content model. expecting: <singleSelectPageTitles>
java.lang.Exception: Invalid xml data
Unfortunately in some of these cases, the line/number markers to help you pinpoint where in the file to locate the cause of this complaint are registered as 0:0. In a large file (e.g. a ContentPack XOG of a Studio object) you can't simply 'eyeball' the XML to look for the cause, and many XML schema validators fail to parse XOG grammar.
First, the reason why many XOG validators fail to parse XOG grammar is because we use multiple schema definition files per request. Meaning, instead of a 1:1 mapping between .xml and .xsd files, our .xsd files have <xsd:include> references to pull in the contents of additional .xsd files (and they may also contain further <xsd:include> references too), and being able to resolve these are critical to having a full XML Schema Definition to validate against.
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
<xsd:element name="NikuDataBus" type="NikuDataBusReadType"/>
But Clarity does this routinely, so it must be possible. There may even be some tools that your company uses that can do this, but if you don't we can leverage the exact same libraries that Clarity uses to perform another parse and help provide us with this information. That library is called msv (multiple schema validation library).
You can download the latest version of this library including a command line usable version of it from here (take the msv*.zip file, the xsdlib*.zip file isn't needed): https://java.net/downloads/msv/releases/
Extract the file to a folder, open a command prompt, and ensure that you have the 'java' command on your path (e.g. typing 'java -version' produces a valid result).
Then all you need to do is this: java -jar msv.jar <your xsd file> <your XOG xml file>
The .xsd files come with your XOG client download in the $XOG_CLIENT/xsd folder, but you have to pick the correct one to use. To do this, first determine if you were performing a XOG 'read' or 'write' action, as indicated in the <Header> line of your XOG file:
<Header version="8.0" action="read" objectType="contentPack" externalSource="NIKU">
If it is 'read' then the XSD file you would provide is your $XOG_CLIENT/xsd/nikuxog_read.xsd
If it is 'write' then your XSD file is likely to be $XOG_CLIENT/xsd/nikuxog_<object>.xsd where <object> is replaced with the objectType from the <Header> attribute (e.g. nikuxog_contentPack.xsd).
Don't use the schema file you see referenced in the NikuDataBus element of the XOG file, there are situations where it isn't the one you want to use, and remember, if you're on a unix-like environment (Mac, AIX, Linux) then you'll have to observe the correct file name case sensitivity.
In my case with the XOG header as above which I just took for example from the XOG Client's portlets_read.xml sample file, I would use this and if all is well, receive the following output:
C:\msv>java -jar msv.jar C:\xogclient\xsd\nikuxog_read.xsd C:\xogclient\xml\portlets_read.xml
start parsing a grammar.
the document is valid.
When there is a problem with parsing, such as a required tag missing from the structure, we will receive the name of the expected tag and now instead of 0:0 we will also hopefully get the line/column where it happened so we can fix it quickly:
C:\msv>java -jar msv.jar C:\xogclient\xsd\nikuxog_contentPack.xsd C:\xogclient\obj_test.xml
start parsing a grammar.
Error at line:579, column:1,030 of file:///C:/xogclient/obj_test.xml
uncompleted content model. expecting: <nls>
the document is NOT valid.
Now we can edit the file and decide, should the <nls> element(s) be added? Or did we even want to XOG this piece of the file in (maybe it was a copy/paste error or extra content we had XOG'd out that we don't need for writing back in again)? In which case, we may just remove or comment out the failing section.
After making a change and saving the XML file, don't forget to parse again with the msv.jar library again. Either new problems could have been introduced as a result of the editing, or more likely, if the parsing error originally found was sufficient enough, it may have been able to mask further errors in the file from being reported or the file integrity may have been impacted enough so that further parsing wasn't even possible. So, keep trying to parse and correct until you have a valid file reported.
If you still have errors with XOG after this point, either your error isn't related to the parsing of the file (whilst XSD validation is a good technique, it isn't able to capture an application's full set of business rules such as finish dates must be equal to or later than start dates, or that attribute X is required when attribute Y is present elsewhere), or you may want to check that your version of the XOG client and the server you are using are a correct match for eachother.