OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: NIMS testing / conformance - input to the discussion


Guys,

One the call Friday, Elysa asked me to share the testing and conformance
approach that NIMS was piloting for the CAP standard.  Attached is the draft
CAP test procedure and a draft test report applying that testing against
DMIS.  Approach input was provided by us, Gary and Sukumar at the time, but
the following summarizes some aspects discussed:

 

From a standards conformance perspective the overall test must prove
interoperability with one to many other / disparate systems by generating /
sending per the standard and by receiving / showing the information as
understandable per the standard.  Both generate/send and receive would check
the same key things:

 

*	XML schema validity (general – valid XML per XML tools)
> I think you have this covered 
*	XML schema validity per the specific standard 

*	All mandatory elements exist in the specified form / format
> I think you have covered whether mandatory elements exist, but not checked
that each element conforms to specified format, code values etc. specified
in the data dictionary.  In the “conformance” test, an XML tool will tell
you whether or not the XML is well-formed, but doesn’t know whether that XML
matches constraints / formats of the standard. 
*	All optional elements exist in the specified form / format
> We discussed testing them all even if the vendor doesn’t plan to use them
all – same checks as mandatory elements.  Then if a vendor decides to use an
optional element they don’t have to repeat testing. 
*	Element cardinality (test multiple vs. single instances of elements)
> Has the procedure confirmed that multiple values are not present where not
allowed, and that they are accommodated where multiples are allowed? 
*	Overall message / XML structure per the standard (overall message
structure / cardinality of message segments)
> Same as the element cardinality issue only at the segment level 
*	Business Rules as they are specified at any level of the structure
(e.g. overall message, specific segments, specific elements)
> I don’t think I saw any checking against business rules of the spec –
those that exist for CAP may only be at the element level… 

 

Gary had also added:

What the schema test does not do is also very important.

1. Does not validate that the strings for <polygon> and <circle> are
properly formed and represent real locations.

2. Does not check to see that the <references> tag content is properly
formed.

 

There are probably a couple of others, but I would have to research the spec
again to be sure. Basically, if the Schema calls for a string, but the spec
puts some rules on the formation or structure of the string, there is
nothing in the schema to check that those rules are enforced.  

 

 

Thanks,

 

Tim

 


No virus found in this outgoing message.
Checked by AVG Free Edition. 
Version: 7.5.485 / Virus Database: 269.13.13/998 - Release Date: 9/10/2007
8:48 AM
 
    

<<attachment: winmail.dat>>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]