Parsing XML problems with Namespace

[aartlett]

I'm getting a problem when I try to parse a XML file which contains namespace info. It also contains some tages xmi:nil=true for some fields.

The XML is (cut down a bit:
<?xml version="1.0" encoding="UTF-8" ?>
<PublishMXSERVITEM xmlns="http://www.ibm.com/maximo" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" baseLanguage="EN" creationDateTime="2009-02-04T16:34:04+11:00" event="0" maximoVersion="7 1 137 V7110-890" messageID="12337256452217794" transLanguage="EN">
<MXSERVITEMSet>
<SERVICEITEMS>
<CUSLOWERLIMIT xsi:nil="true" />
<CUSREQDETAILS>0</CUSREQDETAILS>
<CUSUPPERLIMIT xsi:nil="true" />
<STATUSDATE>2009-01-21T17:20:47+11:00</STATUSDATE>
</SERVICEITEMS>
</MXSERVITEMSet>
</PublishMXSERVITEM>


I hope that is readable. I've dropped a lot of the record, but this amount does work/fail as follows:

As is: no records output
Drop the namespace info: fails due to the xsi:nil="true"
from the xsi:nil="true" and keep namespace info: no records out
drop both namespace and xsi...: 1 record out.

It's a fairly bring folder -> XML -> transofrm -> Seq File
as I'm trying it as a proof of concept from a new feed for us.

The source insist they can't adjust the output as that is how the application produces it. Short of parsing and removing the offending data I've run out of ideas.

Can anyone suggest possible ways forward. More information is of course available if I've missed something pertinent.

[eostic]

I've seen a variety of issues with namespaces over the years, although most recently the issues have been with release 8 and some fixes that are needed (at least one of them, which deals with namespaces, is e117664). However, those fixes are for errors that you aren't getting............still, xsi:nil should work fine -- I've certainly used it in the past.

If I can, I'll try your snippet in my environment and see what happens and at least we'll have a comparison, but check into that patch.

Ernie

[aartlett]

....still, xsi:nil should work fine --

Ernie,
i think the xsi:nill error is a furfy. It only occurs when I drop both of the namespaces from the XML header. I'll try just dropping the MAXIMO one and see how that goes though.

Thanks for helping

UPDATE:
I found an error, the xlsns="http..." for maximo works if I change it to
xlns:maximo="http..." I'm chasing the source to see if they can change their output.

I think I could edit the input record on the fly to change xlsns= xlsns:fred=, actually I'm sure i could. but that is a hack I don't want to really touch.

If anyone can think of another way around I's surely appreciate it.

[eostic]

hmm. Interesting. Not having the maximo on that usually indicates that it is the "default" namespace. Something strange is happening in the parsing rules. I've seen some bizarre things with namespaces and their support among tools and parsers. Symptoms arising here can be difficult to decipher because it's often hard to tell if the tool vendor has a problem, or the standard has a problem, or the parser (in this case apache) has a problem, etc. You can be chasing one of these for a long time. I recently was involved in a scenario where DS couldn't read a WSDL document because of a rarely used xsd property, and it turned out to be a Microsoft anomaly, as we use some of their tooling in the DS Designer to perform imports. ...and I wouldn't fault Microsoft either, as it turned out to be a very rarely used part of the xsd standard. We ultimately had it fixed, incorporating Microsoft's fix, but making the correction at the source corrected the issue long before then.

Having someone change what they put into the source or zapping it afterwords in a well documented transform are often the best solutions.

Ernie

[aartlett]

just a quick update. worked around the problem by doing as I mentioned, an on the fly edit of the xml to change the namespace. seems to be a DS "feature".