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: Re: NIMS testing / conformance - input to the discussion


Thanks Tim,

All in all, it has been one interesting day. This adds a nice touch.

Cheers,
Rex

At 4:54 PM -0400 9/10/07, Timothy Grapes wrote:
>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
>
>


--
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-898-0670


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