Here are some things to think about
when dealing with your ATML vendor.
Your vendor's ATML should validate (not contain errors). Schemas are used to validate the ATML and there are a number of versions out there. Since a newer schema may break your software, always require the matching schema/ATML be under configuration control.
It is possible to produce ATML that validates with only 4 fields completed! Know what data you require in your ATML. If it's appropriate, you may want to ask for an "XSL style sheet" report, so you can verify that all the data is contained in the ATML.
Ask your vendor if their ATML has been extended. Extended software likely will not be interoperable with other software. Vendors extend ATML when they feel the standard does not provide what they need. If your vendor has extended the ATML, you may want to contact the ATML Task Group for their opinion about the extension. They may be able to provide another way to represent the data without extending or may incorporate the extension data in the next standard update.
The ATML standard can sometimes be interpreted in more than one way by vendors, making the ATML non-interoperable in some cases. If you know ahead of time that you want your vendor's ATML to work with another vendor's, then make that a requirement. Don't assume that it will work. Interoperability is the goal, but we all need to work together to make it a reality.
Wirelists ATML describes the connectivity between other ATML modules. Don't expect that any two ATML modules will reference each other perfectly. For example, there is no ATML requirement that the pins in the Test Station ATML have to mate up with pin names in the mating Test Adapter ATML. If there is any question, require a wirelists ATML to clear any ambiguity.
If you think you may want to share your ATML, be clear about who owns the copyright.