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

 


Help: OASIS Mailing Lists Help | MarkMail Help

plcs-dex message

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


Subject: RE: [plcs-dex] Issues with identification and classification


You are right Tim, we did discuss this, and the issue was the availability of the RDL, and the additional overhead of a translator accessing the RDL.

 

In the implementation pilots there was concern that:

a)       the translator was going to have to query the RDL frequently and this would be an overhead.

b)       That an RDL server “May” not be available

 

Hence the proposal.

 

I agree about all concerns being made visible – I am trying to encourage everyone who is working on pilot implementations to join this email exploder.

 

The /IGNORE is correct  -  in that it was agreed as the approach during the recent PLCS synchronization workshops.

As a means of for deliberately saying “ignore” this.

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

-----Original Message-----
From:
Tim Turner [mailto:timturner11@bellsouth.net]
Sent: 31 January 2005 18:32
To: '
David Price'; plcs-dex@lists.oasis-open.org
Cc: 'Örjan Falk';
'Jonas Rosén'; 'Tonning Leif'; 'Magnus Färneland'
Subject: RE: [plcs-dex] Issues with identification and classification

 

Ah - subclasses, ok. So, (with respect to your comment on Rob's suggestion)  I presume that this information can be returned from an RDL query to determine whether the attribute value is an identification_code, a name, application_dmain, life_cycle_domain etc., right?

 

I think all concerns should be made openly & visible to all. I will stand corrected, but mine was that in order to establish which identification_assignment applies to which view_definition_context attribute (application_domain or life_cycle_stage), we will require the results of the query above in order to make the determination.

 

Tim

-----Original Message-----
From: David Price [mailto:david.price@eurostep.com]
Sent: 31 January 2005 12:55
To: plcs-dex@lists.oasis-open.org
Cc: 'Örjan Falk'; 'Jonas Rosén'; 'Tonning Leif'; 'Magnus Färneland'
Subject: RE: [plcs-dex] Issues with identification and classification

Hi Tim,

 

Two comments...

 

In the RDL you don't need class of class to solve this problem, subclassing will work.

 

If we're going to assume no access to the RDL server is a concern, we might as well stop now. That said, the file can still parse... URIs are after all just text strings.

 

Cheers,

David

 

-----Original Message-----
From: Tim Turner [mailto:timturner11@bellsouth.net]
Sent: 31 January 2005 15:29
To: 'David Price'; 'Rob Bodington'; plcs-dex@lists.oasis-open.org
Cc: 'Örjan Falk'; 'Jonas Rosén'; 'Tonning Leif'; 'Magnus Färneland'
Subject: RE: [plcs-dex] Issues with identification and classification

 

Rob/Dave

 

Didn't we discuss this issue of ambiguity once before?

 

I can see both points & both have some (practical) observations;

 

In Rob's version

- using classification of classification is logically fine, but how many orders of classification are we going to allow?

- wasn't this classification of concepts one of the reasons for having an RDL in the first place?

- using classification of classification keeps the parsability with the P21/P28 file should an RDL not be available (for whatever reason)

- we assume that the classification of another class always refers to the target External_class.name (& not to External_class.id, or External_class.description).

 

In Dave's version

- moving the classification to the RDL also makes sense & replaces the overhead from translators in reliance upon the RDL service

- however, if for any reason the RDL service is unavailable, the file will not be parseable (as it will be inherently ambiguous) - which ought to be of practicable concern.

 

Regards,

Tim

 

NB - I presume that the '/IGNORE' on instance #6 of Rob's diagrams should be a $

NNB - Most translators' default behaviour, given an attribute value of $, is that there was no data provided(!) so all this behaviour needs to be specifically coded & as generic as possible.

-----Original Message-----
From: David Price [mailto:david.price@eurostep.com]
Sent: 31 January 2005 07:39
To: 'Rob Bodington'; plcs-dex@lists.oasis-open.org
Cc: 'Örjan Falk'; 'Jonas Rosén'; 'Tonning, Leif'; 'Magnus Färneland'
Subject: RE: [plcs-dex] Issues with identification and classification

Rob,

 

I think the fundamental approach here has a problem. Whether part_code is a kind of  name or kind of identifier is schema-level information, not data exchange level information. Therefore, that statement has to be made within the RDL itself, not in the exchange file. How could a Web service present the possible types of names for something if that statement isn't in the RDL?

 

Cheers,

David

 

-----Original Message-----
From: Rob Bodington [mailto:rob.bodington@eurostep.com]
Sent: 31 January 2005 07:28
To: plcs-dex@lists.oasis-open.org
Cc: Örjan Falk; Jonas Rosén; Tonning, Leif; Magnus Färneland
Subject: [plcs-dex] Issues with identification and classification

 

Hi

During the development of PLCS translators we have identified a couple of issues with the way in which we use classification of attribute and with the use of "role" in identification.

 

I have documented what the issues are in the attached document and proposed a solution.

 

Are the proposals acceptable to everyone?

 

If so, we will need to modify the relevant capabilities.

 

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
Fax:    +44 (0)1454 270031 

 



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