[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [plcs-dex] RE: Capability property value ranges
Hi Peter,
For
the issue about document properties, I think the rule is saying that for
each instance of assigned_document_property, it must point to one item in the
described_element select list (document_definition/file etc..), which I think is
fair; if you're going to bother to define a property you might as well assign it
to the document it is defined for. This only reinforces the fact that each
property must be represented separately (rather than a list/set etc..). There
can be many descriptive_document_property or numerical_document_property
instances assigned to each described_element (e.g. no of pages, weight, size
etc.).
The 30
rules on assigned_property.described_element select type basically serve to
limit the 32 choices in the select type referenced down to 2
(document_definition/file)... which is an odd way of achieving the requirement,
but legal from what I can tell (note this is done elsewhere within PLCS
also).
I
raised the subject of why documents had to be dealt with differently around 1.5
yrs ago & after a long discussion had to create another capability for this
purpose. It is still foggy in my mind what the reasons were, but I guess we
could trawl the archive. If C076 can cover the template requirements for
document properties then I think that would be useful, but we then would need to
move the contents of C087 somewhere which I'm not certain would make others so
happy & may complicate what we have. So we might need to keep C087, however,
the template could easily be referenced from C076 for the purposes of properties
though we have to ensure that whichever template is used doesn't allow illegal
associations to be made. I suspect that the template for docs will need to be
based upon that for products but may need to prune out the unecessary items
& include those specific for docs.
Other
points below accepted
regards,
Tim
From: Peter Bergström [mailto:peter.bergstrom@eurostep.com] Sent: 22 May 2006 13:39 To: 'Tim Turner'; 'Hendrix, Thomas E' Cc: plcs-dex@lists.oasis-open.org Subject: RE: [plcs-dex] RE: Capability property value ranges Thanks Tim, I think I
have understood your requirements, and propose to do the
following: 1)
In Cap00
Repr_value_with_unit I will include your template repr_value_with_unit. I
propose to change the in-parameter name unit_class_name to unit (you need to
change your figures accordingly). 2)
In Cap079
Repr_properties_numerically I will leave the template
repr_properties_numerically (I never intended to remove it, but was not clear
earlier). 3)
I will not
use your template Repr_numerical_value_with_unit, since I can't find a need for
it (since we have what's needed for properties in cap079). If an example is
provided (same as above) I will instead include the reference parameter in the
template repr_properties_numerically, and that will solve
that. Regarding
document_properties, I'm terribly confused. I tried to include them in the full
property-solution, but was flabbergasted by the express where rule
wr1: ENTITY
Assigned_document_property SUBTYPE OF
(Assigned_property);
SELF\Assigned_property.described_element :
document_property_item; DERIVE
SELF\Assigned_property.name : STRING := 'document
property'; UNIQUE UR1
: SELF\Assigned_property.described_element; WHERE WR1
: SIZEOF(['AP239_PRODUCT_LIFE_CYCLE_SUPPORT_ARM_LF.DOCUMENT_DEFINITION',
'AP239_PRODUCT_LIFE_CYCLE_SUPPORT_ARM_LF.FILE'] *
TYPEOF(SELF\
Assigned_property.described_element)) = 1; END_ENTITY; (* declared
in: Document_properties_arm *) Hopefully I have
misunderstood the rule, but as far as I understand, a document must have ONE AND
EXACTLY ONE property !!! If this is true, the
entire document_property part of the model is crap, and we should just ignore
it. A Document is a subtype of Product, so why treat it differently - Use
Product-properties!! And really, even if I
have misunderstood the document property rule above, why _would_ we treat document properties
different from any other product properties? I would just add to the confusion,
IMHO. My proposal is to write
in the cap076 that it applies for all subtypes of Product (including Document),
and remove Cap087. Peter From: Tim
Turner [mailto:tjt@lsc.co.uk] Hi
Peter, I have made some
observations below. Hopefully, it clarifies your questions
:-) regards, Tim From: Peter
Bergström [mailto: Hi
Tim, Now I have looked at
your templates, and the way you use them, and I have a few
questions: In your template
representing_numerical_value_with_unit you have included the
Property_value_representation entity, but as far as I understand from Cap
Representing_location you are not using it. The inclusion appears to have been a
copy-paste mistake. If so, I think I understand your requirements (i.e.
everything but Property_value_representation. The reason
for including the Property_value_representation is that for complex
subtypes of Value_with_unit e.g. Numerical_value_with_unit there is a
rule which states that it must be referenced by an instance of representation
(as a .item if I remember). The point is that you cannot just instantiate the
NIWU by itself due to the rule inherited by
Measure_item. For locations, it is
only required to use Value_with_unit, which then removes the requirement for a
separate representation (it is not a subtype of Measure_item). The
representation, however, is useful for associating the values with a product,
property or process (for which there are the relevant hooks in those parts of
the model) - however, Location is (unfortunately) none of the
above. I can see two
resolutions here: 1) I change the
Representing_numerical_value in cap Representing_properties_numerically to
include a reference parameter ^item, in which case you would get exactly what
you have now, or 2) I edit your
representing_numerical_value_with_unit by deleting the
Property_value_representation entity, and use that in
Representing_numerical_value. It would then have a reference parameter ^item,
and it would be located in Cap
Representing_value_with_unit. The first choice is the
easiest for me, but kind of cludgy, so I think I go for the second choice.
So I would keep your
existing Representing_numerical_value
in C079, but make the NVWU referenceable. I also recommend adding the template
for Value_with_unit to C00, as is. I'm however not sure
that I will include the representing_value_with_unit template in Cap
Representing_value_with_unit. To me, I can't see the difference between a value
with unit and a numerical value with unit, and it seem to me that it will only
confuse issues ('which one is applicable where?'). Can you or someone else
enlighten me regarding their difference? Also, bear in mind that
there is also the document_property_representation which will need to re-use
some of these templates as this is not
covered. Comments? Cheers, Peter From: Tim
Turner [mailto:tjt@lsc.co.uk] Hi
Peter, For your
info, I have just managed to get my sourcefoge account operational again &
have uploaded some work from last week during the
outage. Inside
representing_location, you will see that there are 7 templates - 2 of which are
additional templates that were done during development of this capability. These
are; representing_value_with_unit (- the previous one in C00 - version 1.6 had
many errors) & representing_numerical_value_with_unit. The first should be
moved to the appropriate place while the second was found not to be necessary -
but I have left it since it works & may serve a purpose
sometime. Kind
regards, NB - all
work without error in GI -----Original Message----- Peter, Regards, Tom Thomas E.
Hendrix -----Original Message----- Tom, I'm editing
the property capabilities in DEXlib now, and need three templates in cap
representing_property_value_ranges, one for range, one for limit and one for
value with tolerance. Can I take
over the editorship temporarily, or will you do it?
Peter
Bergström 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 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 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]