| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Chris
-----Original Message-----
From:
owner-stds-scc20-atml@LISTSERV.IEEE.ORG [mailto:owner-stds-scc20-atml@LISTSERV.IEEE.ORG]
On Behalf Of Ralph, John (Mission Systems)
Sent: 04 April 2005 19:51
To:
stds-scc20-atml@LISTSERV.IEEE.ORG
Cc:
anthony.l.alwardt@boeing.com
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.
<CCG>There is an agenda item to
discuss this for the ATML telecon 7 April 2005 should we need
it.
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.
<CCG>Strickly speaking a TestResults instance document does not restrict the TestResults to one UUT or one TestProgram for that matter, however a single TestResults instance document can only reference one UUT, TestStation, TestProgram element. Not of any particular use in this case but the testresults are a user defined collection of results.
<CCG>As John indicated the instance documents provide for user defined collection of TestResults that share a common theme. This is generally true of all ATML components. If we a use case to support supporting collection of TestResults (or any other ATML collection) which represents a colection of what would otherwise be instance documents, I'd like to see this in a seperate schema, prehaps a type in common from which users could develop their own packaging mechanism.
<CCG>Tony is their merit in revisiting this
single instance vs multiple instance to review how many other schemas could potentially run into the same problem, and look to slove at a
global/architectural level?
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.
<CCG>Well spotted do we have a
proposal for a change?
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.
<CCG>I believe making <TestData> an optional tag is a good idea. - I remember a use case where we wanted to just hold a list of limits in ATML, making <TestData> would allow TestResults to forfuill that use case. What does our style say about having optional elements with only optional elements, should it be a - one or more of the following (with no duplicates)
<CCG> Tony I assume you stumbled
across this because you needed <Indictments> not available at the
<Test> level, which meant you had to use the <TestResult>
element?
Tony Alwardt
The Boeing Company
Integrated Defense
Systems
Phone: (314) 234-1413
Fax: (314) 232-0443
E-Mail:
anthony.l.alwardt@boeing.com