0

We ran into an issue while parsing the external XML against our specific XSD. We have external vendor XML feed that keeps on changing (they add more attributes to the XML, which are not defined in the XSD), breaking our code. We need to identify the way by which we can avoid the issue when external vendor adds more attributes. We will not have any idea when they will be going to add new fields. We also need our XSD in place to validate against the attributes. Any suggestions will be highly appreciated!

kjhughes
  • 106,133
  • 27
  • 181
  • 240
user4067046
  • 21
  • 6
  • 1
    Either educate your vendor to send valid XML; or forget about your XSD and do some ad-hoc parsing – Gyro Gearless Sep 22 '14 at 15:18
  • @kjhughes Thanks Gyro, but in case we take away our XSD, isn't that then there would be no way to establish the validity(as per our business rules) of the xml data passed to us.We can parse the xml to confirm the well-formedness, but is there a way to establish the validity with parsing. Please suggest. – user4067046 Sep 22 '14 at 20:14

2 Answers2

0

Ideally, you should hold your vendor to providing XML that validates against your XSD, and they should have to request additions to the XSD formally when needed. It is, afterall, the purpose of the XSD to govern such agreements.

If you can't make that work, and are willing to sacrifice the benefits of such an explicit agreement, you could consider allowing any attributes on those elements that your vendor just can't seem to leave alone. XML Schema has an xs:anyAttribute construct that supports this notion.

Note that you will likely want to use the lax value for processContents to indicate that if a global attribute declaration exists, it should be used, otherwise, it may be skipped without invalidating the entire document.

For example:

<xs:complexType name="SomeType">
  <xs:attribute name="a1" type="xs:int" use="required" />
  <xs:anyAttribute processContents="lax" />
</xs:complexType>
kjhughes
  • 106,133
  • 27
  • 181
  • 240
  • thanks for the input. We tested and it seemed to be working.However, the things we found are that we need to declare tag in all the elements for which we are expecting vendor might add additional attributes.One declaration of this tag will allow n number of attributes to be passed in the xml without breaking our code. – user4067046 Sep 24 '14 at 14:50
  • On the other hand, in case vendor added extra element, we need to declare tag. However, we can declare only one tag and one tag will allow only one additional element to be passed in the XML. In case, vendor passes more than one additional child elements, our code will break as we can not declare multiple elements consecutively under one parent element becus it throws unique particle attribution exception. – user4067046 Sep 24 '14 at 14:51
  • We tried to find any reference material and couldnt find any good reference. Please suggest if you can point to good resources on this topic.Once again, thanks a lot for your help! – user4067046 Sep 24 '14 at 14:52
  • Yes, the more places your vendor cannot be held to follow the XSD, the more liberally you'll have to sprinkle `xs:any` and `xs:anyAttributes` around your XSD. At some point, you might as well give up validating altogether. I [answered a question](http://stackoverflow.com/a/26004925/290085) recently about an "[XML schema that allows anything](http://stackoverflow.com/q/26003982/290085)" that you might find interesting: Given only a specific root element, it allows any attributes on it and any XML under it. – kjhughes Sep 24 '14 at 14:59
0

This is more a commercial question that a techical one. What do you do when a restaurant serves poor food? It depends how hungry you are. In an ideal world you complain, and if they don't fix the problem you refuse to pay. But if they are the only source of food in town, or if you're not paying anyway, you might have little choice but to eat their stuff regardless of quality.

Whatever your negotiating position, you need to talk to them and explain why the stuff they are producing doesn't meet your requirements.

Michael Kay
  • 156,231
  • 11
  • 92
  • 164