OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

plcs-tog message

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


Subject: RE: [plcs-tog] Next telecon?


Title: Next telecon?

We also need to resolve the fairly major issue of how to represent reference data templates e.g. assigning_codes / assigning_reference_data, assigning_business_reference_data that I raised in an earlier email (attached)

 

Regards
Rob

-----Original Message-----
From: Nigel Newling [mailto:nfn@lsc.co.uk]
Sent: 28 October 2005 09:53
To: 'plcs-tog@lists.oasis-open.org'
Subject: [plcs-tog] Next telecon?

 

We seem to have lost the programme of teleconferences that was proposed in Glasgow. Now that work has commenced on DEX 4, with a good prospect of a start on DEX 1 & 8 as well, there is now an urgent need for a forum to address the cloud of issues that the work is throwing up. These range from the simple typo or spelling mistake through to the detailed technical, but all need to be resolved if we are to get DEXs reliably into use. Some merely require commitment of the document editor to correct, others will require direction from the TOG

I attach a spreadsheet to demonstrate the problems I face as Team Leader, Team 4. Most of the entries will shortly re-appear as issues raised against Capabilities , but some will have to be brought to the TOG. I have decided, however, to release the spreadsheet now to give TOG members a 'head-up' on the amount and nature of issues that will have to be resolved before the end of the year if I am to hold to the implementation programme currently in planned for MoD / DML.

Nigel

<<cap_entity_issues.xls>>

N F Newling BSc CEng MIEE
Executive Consultant, LSC Group
P.O. Box 77,
Devonport House, Durley Park,
Keynsham, Bristol
BS31 2YH
Tel : +44 117 916 1651
Mobile : +44 7734 742975

 

DISCLAIMER: ***SECURITY LABEL: NOT PROTECTIVELY MARKED***   The information in this message is confidential and may be legally privileged. It is intended solely for the addressee.  Access to this message by anyone else is unauthorised.  If you are not the intended recipient, any disclosure, copying, or distribution of the message, or any action or omission taken by you in reliance on it, is prohibited and may be unlawful.  Please immediately contact the sender if you have received this message in error. This e-mail originates from LSC Group. Registered in England & Wales No 2275471 Registered Office: Devonport Royal Dockyard, Devonport, Plymouth, PL1 4SG

 

--- Begin Message ---

Hi

I have just raised this major issue capabilities/assigning_reference_data/dvlp/issues.xml#RBN-7

against assigning_reference_data

 

<!-- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->

<issue

   id="RBN-7"

   type="general"

   status="open"

   category="minor_technical"

   by="Rob Bodington"

   date="05-10-25">

<description>

There are currently three templates specifying different ways of assigning reference data:

assigning_business_specific_reference_data

assigning_reference_data

assigning_code

 

Assigning_reference_data is used by default in most templates that need reference data

e.g. assigning_organization.

 

However,  in different situations, each of the three approaches to

assigning reference data is appropriate. This then raises the question as

to how to represent this within a template such as assigning_organization.

 

 

Option 1) We could have three templates for assigning_organization. One

for each use of reference data. This would not really address the problem

as any template using assigning_organization has the same problem.

 

Option 2) We could exclude the assigning_reference_data from

templates. This has a disadvantage in that the reference data may be

inconsistently applied or not applied.

 

Option 3) Always use assigning_reference_data in other templates. Document

the fact that when assigning_reference_data is used

either assigning_business_specific_reference_data, or assigning_codes could

be used instead. In fact, it could be argued, that only

assigning_business_specific_reference_data or assigning_codes should be

used. As both have the same template arguments, we avoid any problems.

Perhaps we need a special parameter set for class information that

indicates whether the class is standard, business or a code.

Furthermore, the instantiation patterns of

assigning_business_specific_reference_data and assigning_codes are

different, one uses classification_assignment to relate two classes, the

other uses Subset - they should use the same.

 

</description>

Regards
Rob

-------------------------------------------   
Rob Bodington
Eurostep Limited
Web Page:
http://www.eurostep.com http://www.share-a-space.com
Email: Rob.Bodington@eurostep.com
Phone: +44 (0)1454 270030
Mobile: +44 (0)7796 176 401

 

--- End Message ---


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