Here are some things to think about
when dealing with your ATML vendor.
Validation and
Configuration Control
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.
Missing Fields
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.
Extensions
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.
Incompatibility
between vendors
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.
Connect the
modules
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.
Copyright
If you think you may want to share your
ATML, be clear about who owns the copyright.
|
_text_