RE: [plcs] Posponed conference call to next week + Draft version ofReview check list for capabilities

["Barker, Sean (UK)" <sean.barker@baesystems.com>]

Title: Posponed conference call to next week + Draft version of Review check list for capabilities

Trine,

    I will not be available for the conference call. I disagree with some elements of the checklist.

 

Para #8: The list of subsections is, as written, too restrictive. Representing_task will not conform to this if posed as a normative order, and making it do so would make it unreadable.

 

Para #12: The combination "EXPRESS-G" and "illustrating the main entities" is an oxymoron. Change to "EXPRESS-G like".

Colour coding - some guidance is needed on what makes good colour coding, given that some readers are colour blind.

 

Para #13: "There should be no...limits... to AP239". The capability makes assumptions about the module hierarchy (e.g. that the *characterized module is used) . I suspect that it is currently too difficult to make make clear what is AP 239 specific and what isn't.

 

Para #14: Second sentence makes no sense.

 

Para #15: Currently reads everything that can be classified must be classified. This makes no sense. It also conflicts with the intent of making the capabilities applicable beyond AP 239.

There is an important distinction to be made between model reference data, which is needed to ensure that the model is capable of being interpreted, and application reference data, which defines the particular distinctions and restrictions within the scope of the application. I do not understand the concept "descriptive reference data". There should, however, be guidance on how the reference data can be extended.

 

Para #16: Envelope was deliberately written not to use identifier_assignment, and it would not be practicable to make it do so.

 

Sentence starting "Has all relevant entities..." - I do not understand

 

The requirement that examples be compliant with AP239 - this is not practical, as the example would become too large to show, and the essence would be lost in the noise of detail. The point of examples is that they show what is relevant to the problem, and will therefore not be compliant. What is required is that the instance model that is being illustrated by the example is compliant in the area that it is illustrating.

 

para #23 It is not our concern if a "referenced standard makes sense", but whether the reference to a standard is complete, correct and appropriate.

 

Usage: The first paragraph is not clear, and I'm not sure the requirement makes sense. It seems to say that you use a date/time as a dependent capability, then you should include date_time_assignment in the usage section. Is this correct? However, surely this usage is implied by it being a dependent capability.

 

Sean Barker
ATC Filton
0117 302 8184

-----Original Message-----
From: Trine.Hansen@dnv.com [mailto:Trine.Hansen@dnv.com]
Sent: 02 June 2004 07:36
To: plcs@lists.oasis-open.org
Subject: [plcs] Posponed conference call to next week + Draft version of Review check list for capabilities

*** WARNING *** This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message.

All.

Modeller review check list for capabilities - Draft
Attached is the first draft of a review checklist for modeller review of capabilities. Please send any comments to Leif and myself, preferable on the OASIS/DEX exploder. We plan to move the content of the check list into a format similar to check lists applied for the PLCS modules.

Conference call today – postponed to next week?
I proposed a conference call today (2 June) for discussion of the review check list. Since the check list is sent out for comments today (and not last week as planned) I suggest we move the conference call to next week – Tuesday 8 June?

<<20040531 - Check list capability modeller review.doc>>

Best Regards
Trine Hansen
UCTNO940, Information Quality Management
Det Norske Veritas AS
( + 47 67 57 96 38 (office)
( + 47 90 83 44 24 (mobile)
* trine.hansen@dnv.com
http://www.dnv.com

**************************************************************
Neither the confidentiality nor the integrity of this message can be guaranteed following transmission on the Internet.
All messages sent to a DNV email addressee are swept by Sybari Antigen for the presence of computer viruses.
DNV acknowledges that SPAM email represents a potential security risk, and DNVs filters to block unwanted emails are therefore continuously adjusted. DNV has disabled "out of office" replies to the Internet
**************************************************************

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************