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] Business_specific reference data in representing_part


Title: RE: [plcs-dex] Business_specific reference data in representing_part

Peter & All,

I am unable to into this issue in depth, but I am in complete agreement with David.

I could be mis-interpreting this, but I thought that having a set of agreed reference data was the whole point. Changes to the reference data are supposed to be easier and more maintainable than re-issuing SC4 standards when that data changes.

Practically, a local copy can survice for when access to the internet cannot be found.

It means that exchange partners must agree to use a standard (set of) ref data (as published through Maintenance Agency X?). That may be across a large domain (e.g. extended enterprise) or smaller (e.g. local businesses).

As a new partner, to correctly read an exchange file, you will either need to locate the resource library and access online, or download a local copy.

The M.A. will have rules to govern how/what/when/who publishes standard ref data. Hence the problem shifts from AP team(s) to ref data team(s) : -)

Regards,
Tim

NB I think this relates to a previous mail from Rob about agreeing upon a standard set of ref data for view_definition_context(s). I think the outcome of this was to at least enable those already required for the PDM Schema.

NB2. I think your suggested change will affect all capabilities/templates that revolve around a Product or subtype of product.

-----Original Message-----
From: David Price [mailto:david.price@eurostep.com]
Sent: 23 January 2007 08:45
To: plcs-dex@lists.oasis-open.org
Subject: Re: [plcs-dex] Business_specific reference data in representing_part

All,

Sounds to me like the DEX development may be mixing standardization with implementation - not a good thing.

Comments like "If we demand <RDL access>, post-processors will be slowed down significantly, and imports will be vulnerable to internet down-periods and such." are a typical example. Specifying that an RD class is identified as http://www.example.com/rd/projectx/classY and is standardized in a set of OWL ontologies says almost nothing about how a post-processor actually accesses the RD at runtime.

I'd suggest that the TC needs to be making it clear that PLCS DEX-based exchange *depends on RD* - full stop. The TC should also not put artificial burdens on pre-precessors based on unsubstantiated post-processor efficiency issues (i.e. you could actually be making things worse). It should leave it to implementors to figure out how to efficiently access an exchange file and the related RD. The TC can't know what technology, platform, scale or requirements implementor/user organizations have in mind and so details about how implementors make processors efficient are not something TC should be enforcing at this point in time.

Cheers,
David

On Monday 22 January 2007 16:38, Peter Bergström wrote:
> Tim,
>
>
>
> I would like you to change the reference data template used for
> view_definition_context life_cycle_stage and application_domain in template
> representing_part from assigning_reference_data to
> assigning_business_specific_reference_data.
>
>
>
> This issue comes from implementing post-processors, where it is not always
> possible to know what reference data should be mapped to what attribute of
> view_definition_context without having access to the correct RDL. This
> happens as soon as other values is used than those defined in the OASIS
> standard reference data library. An example: If I chose to define
> 'production' as a life cycle stage and 'electronics' as an application
> domain, it is impossible for computers to understand what value belongs to
> which attribute (or field), without access to the RDL.
>
>
>
> I do not intend that it should be OK to import files without performing a
> validation of the import file, and consolidation with internal data. I do
> think, however, that we should not mandate how the exact implementation of
> the import is done (i.e. in what order the different steps are performed,
> e.g. validating P28 against xml-schema, cashing data into internal memory,
> consolidating against existing data, load data, or whatever the steps are).
> A post-processor must be able to perform validation and consolidation of
> data, but it does not have to know the definition of reference data, or
> what the content of the file really means. It just need enough data to
> perform its job.
>
>
>
> I'm not saying that a PLCS file should be understandable without access to
> the RDL at all times, but I'm saying that for a post-processor to be able
> to load and compare an exchange file with the internal database, the access
> to the RDL must not required. If we demand that, post-processors will be
> slowed down significantly, and imports will be vulnerable to internet
> down-periods and such. But with a simple use of
> assigning_business_specific_reference_data for all cases where there are
> two assignments of reference data to one entity, where they are supposed to
> be mapped against two discrete attributes or fields in the database, this
> problem will be easily overcome. This does not apply to cases when you have
> multiple classifications, since all those values should be mapped to the
> same field or concept. The only occurrence I know of is for the
> view_definition_context where we have life_cycle_stage and
> application_domain, and they are impossible to separate or combine without
> the RDL, as the template is written now. This may also be the case where we
> have both identifier and name attributes for data where it is not possible
> to separate a name from an identification using string comparisons, for
> instance. However, there are not many entities which have both a required
> name and a required identifier, and even less templates that requires both.
> I know that the view_definition_context is a problem for post-processors.
>
>
>
> And if we do not build in a solution to this problem already in the DEXlib
> templates, we will never be able to build post_processors that can operate
> optimized without immediate access to RDLs.
>
>
>
> So please, could you change the use of asg_ref_data in template
> representing_part into asg_business_specific_ref_data (with fixed values
> for the plcs_class)? This change does not change the parameters defined,
> only the path (and the diagrams), so it is really a quite harmless change.
>
>
>
> See template representing_product_as_realized as an example.
>
> Peter
>
>
> This message contains information that may be privileged or confidential
> and is the property of Eurostep Group. It is intended only for the person
> to whom it is addressed. If you are not the intended recipient, you are not
> authorized to read, print, retain, copy, disseminate, distribute, or use
> this message or any part thereof. If you receive this message in error,
> please notify the sender immediately and delete all copies of this message.

--
Mobile +44 7788 561308
UK +44 2072217307
Skype +1 336 283 0606


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




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