RE: TRML Schema Discussion
All -
The comments below are submitted by Tony Alwardt and relate to P1636.1
Test Results - they were forwarded to ATML and the TII group but should
have (also) been posted on the DMC listserv since DMC is the responsible
SCC20 subcommittee.
Regards,
Tim
_________________________________
Timothy J. Wilmering
'314.234.6781
*<mailto:timothy.j.wilmering@boeing.com>
> -----Original Message-----
> From: Ralph, John (Mission Systems) [mailto:John.Ralph@NGC.COM]
> Sent: Monday, April 04, 2005 1:51 PM
> To: stds-scc20-atml@LISTSERV.IEEE.ORG
> Cc: Alwardt, Anthony L
> Subject: FW: TRML Schema Discussion
>
>
> Please post replies to stds-scc20-atml@listserv.ieee.org
>
> Responses from John Ralph preceded by -->
>
> -----Original Message-----
> From: owner-stds-aiestate-member@LISTSERV.IEEE.ORG
> [mailto:owner-stds-aiestate-member@LISTSERV.IEEE.ORG] On Behalf Of
> Alwardt, Anthony L
> Sent: Friday, April 01, 2005 09:37
> To: stds-aiestate-member@LISTSERV.IEEE.ORG
> Subject: TRML Schema Discussion
>
> All,
>
> I have been utilizing the latest TRML schema that is in
> candidate format
> and have noticed the following items that I would like to
> throw out for
> discussion within the group:
>
> 1. The current TRML schema allows extending the
> <TestResults><ResultSet><Test> element via the utilization of the
> built-in <Extension> tag. It seems logical that the
> <TestResults><ResultSet><TestGroup> element should support the use of
> this same extension mechanism. I have validated a
> requirement for such
> an extension on several platforms within Boeing but am
> curious if others
> within the industry have such requirements.
>
> --> No direct response on the requirement for an extension mechanism
> with <TestGroup>; however, there are general questions
> regarding the use
> of extensions. Some feel that no explicit mechanism needs to
> be provided
> as any extension made should be specific to your use case. In other
> words - make any change you want, just don't call the resulting schema
> "ATML compliant". This will be discussed in more detail over the next
> few weeks.
>
>
> 2. I have several use cases which require the storage of Test Results
> for multiple UUT's within the same XML instance document but
> the current
> schema only supports the storage of TestResults for a singular UUT per
> XML instance document. In situations when batch, or off-line,
> processing of TestResults is a requirement it seems beneficial for the
> TRML schema to support allowing the packaging of all the TestResults
> data up into one instance document instead of having to deal with
> multiple instance documents (especially in situations where it is
> desirable to minimize network chatter). One potential enhancement to
> the existing TRML schema that would support adding this functionality
> would be to add new XML root element above the current <TestResults>
> root element and then making a multiplicity relationship
> between the new
> root element and the <TestResults> child element be 1 to many. With
> this enhancement users could continue to store one UUT's worth of Test
> Results data in the instance document as they are doing
> today, but they
> could also store multiple UUT's Test Results within the same instance
> document.
>
> --> The concensus throughout the design process for Test Results was
> that one instance document should contain results for one UUT. This
> makes even more sense if your use case is to store the full instance
> document (vs parsing and putting it into a database). Given
> the typical
> size of an instance document and the speed of most networks,
> I seriously
> doubt that keeping things as is will cause noticable network loading.
>
>
> 3. The current TRML schema has a constraint between the
> <TestResults><UUT> element and the
> <TestResults><Indictments><Indictment> element. In the schema, the
> <TestResults><UUT> element represents the unit that is being
> testing. In
> practicality, most test programs do not indict the UUT they
> are testing,
> but they instead indict a sub-assembly within the UUT that they are
> testing which goes against the way the schema is currently structured.
> Therefore, it seems like the <TestResults><Indictments>
> element is of no
> value within the current schema. However, the
> <TestResults><ResultSet><Test><TestResult><Indictments><Indictment>
> element is of value because this element can be used to store the
> sub-assembly indictments that a test program makes when performing a
> Test. Therefore, my recommendation would be to remove the
> <TestResults><Indictments><Indictment> & <TestResults><Indictments>
> elements and leave the
> <TestResults><ResultSet><Test><TestResult><Indictments> &
> <TestResults><ResultSet><Test><TestResult><Indictments><Indictment>
> elements unless someone has a use case that I have not thought of.
>
> --> You are correct, the linkage is incorrect. The top-level <UUT>
> element is intended to identify the subject of the Test
> Results instance
> document. It doesn't make much sense to link <Indictment> to this.
> Instead, the <Incictment> element should point to some external UUT
> instance document, or merely list the part number/NSN of the indicted
> part.
>
>
> 4. Different software test executives have different modes
> of operation
> in which the user can control how much data gets logged in the Test
> Results. There are situations, especially in classified processing,
> where the user elects to only log the output results of a Test and not
> the data used to perform the Test. The current schema requires the
> <TestData> child tag for every <TestResult> tag but in the classified
> processing use case, the information required by the <TestData> tag is
> not accessible. Would it make more sense to the make the
> <TestData> tag
> optional? If the current schema is not changed, the classified
> processing scenarios can be overcome by placing dummy data within the
> <TestData> element but this solution isn't ideal.
>
> --> I agree completely that it is desirable to have instance documents
> with only UUT and "outcome" information. However, TestData is only
> required if TestResults.ResultSet.Test.TestResult appears. The Test
> element has an Outcome child element and Test has cardinality 0..n so
> multiple Test.Outcome structures are possible. I believe this
> could meet
> your needs, but might be limiting as there would be no method for
> defining a different Indictment for each Test.Outcome. I
> agree with the
> suggestion to make TestResults.ResultSet.Test.TestResult.TestData
> optional might be a reasonable approach.
>
>
> Tony Alwardt
> The Boeing Company
> Integrated Defense Systems
> Phone: (314) 234-1413
> Fax: (314) 232-0443
> E-Mail: anthony.l.alwardt@boeing.com
>