Comments (posted everywhere) are below
Tony
From:
Chris.Gorringe@racalinstrumentsgroup.co.uk
[mailto:Chris.Gorringe@racalinstrumentsgroup.co.uk]
Sent: Wednesday, April 06, 2005
9:17 AM
To:
stds-scc20-atml@LISTSERV.IEEE.ORG; stds-aiestate-member@LISTSERV.IEEE.ORG
Cc: Alwardt, Anthony L; John.Ralph@NGC.COM
Subject: RE: TRML Schema
Discussion
Comments
(posted everywhere) are below
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.
<TA>I agree that this item warrants further discussion
in the telecom</TA>
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?
<TA>Chris, I agree that there
is merit in revisiting the single instance vs multiple instance issue at a higher
architectural level.</TA>
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?
<TA>My proposal for change is stated in the latest
sentence of item #3 above.</TA>
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?
<TA>Chris, Yes I did stumble across this issue in the
case that you mentioned for <Indictments></TA>
Tony Alwardt
The Boeing Company
Integrated Defense Systems
Phone: (314) 234-1413
Fax: (314) 232-0443
E-Mail: anthony.l.alwardt@boeing.com
**********************************************************************
IMPORTANT NOTICE
The information contained in this e-mail is confidential. It may also
be legally privileged. It is intended only for the stated addressee(s)
and access to it by any other person is unauthorised. If you are not
an addressee, you must not disclose, copy, circulate or in any other
way use or rely on the information contained in this e-mail. Such
unauthorised use may be unlawful.
If you have received this e-mail in error, please inform
Racal Instruments Group Ltd. immediately by
emailing postmaster@racalinstrumentsgroup.co.uk
or
phoning +44 (0)1202 872800 (ask for the I.T. Dept.)
and delete it and all copies from your system.
www.racalinstrumentsgroup.co.uk
**********************************************************************