[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [plcs-dex] RE: Capability property value ranges
|
Hi Rob,
I don't think the selects or their population
is a problem - however, Document_property_representation has a function (valid_document_property_representation) which
restricts the values of the .name attributes of document properties assigned.
Hence for a document_property_representation with a .name of "document content"
the document property.name must be one of "detail value", 'geometry type', or
'real world scale'. If 'document creation' is used then it restricts to one of
'creating interface', 'creating system', or 'operating system'
etc..
Clearly, this function needs to be removed or
re-engineered now as it enforces certain combinations of the .name
attributes for Document_property_representation and the Representation.items,
which should probably be given in reference data to be consistent with the rest
of the approach. Else, we shall get errors for using /IGNORE in those places.
However, I think these points may be compensated
through careful reference data
structuring.
Also, we may need to
think about WR2: the context_of_items.kind = 'document
parameters'.
Here is the full text of
the entity & function (which is refered to by WR3 of Document_property_representation):-
ENTITY
document_property_representation
SUBTYPE OF(representation);
SELF\representation.items : SET [1:?] OF
descriptive_or_numerical;
WHERE
WR1 : SIZEOF(QUERY(pr <*
USEDIN(SELF,
'AP239_PRODUCT_LIFE_CYCLE_SUPPORT_ARM_LF.PROPERTY_REPRESENTATION.REP')
|
'AP239_PRODUCT_LIFE_CYCLE_SUPPORT_ARM_LF.ASSIGNED_PROPERTY' IN
TYPEOF(pr.
property))) > 0;
WR2 :
SELF\Representation.context_of_items.kind = 'document parameters';
WR3 :
valid_document_property_representation(SELF);
WR4 : SIZEOF(QUERY(it1 <*
SELF\Representation.items | SIZEOF(QUERY(it2 <*
SELF\Representation.items | it1.name =
it2.name)) > 1)) = 0;
END_ENTITY;
FUNCTION
valid_document_property_representation
(rep : Document_property_representation) : LOGICAL; CASE rep.name OF 'document content' : BEGIN RETURN (SIZEOF(QUERY(items <* rep\Representation.items | NOT (items. name IN ['detail level', 'geometry type', 'real world scale']))) = 0); END; 'document creation' : BEGIN IF NOT (SIZEOF(QUERY(items <* rep\Representation.items | NOT (items. name IN ['creating interface', 'creating system', 'operating system'])) ) = 0) THEN RETURN (FALSE); END_IF; IF NOT (SIZEOF(QUERY(items <* rep\Representation.items | NOT (items. name IN ['creating system']))) = 1) THEN RETURN (FALSE); ELSE RETURN (TRUE); END_IF; END; 'document format' : BEGIN RETURN (SIZEOF(QUERY(items <* rep\Representation.items | NOT (items. name IN ['character code', 'data format', 'size format', 'size format standard']))) = 0); END; 'document size' : BEGIN RETURN (SIZEOF(QUERY(items <* rep\Representation.items | NOT (items. name IN ['file size', 'page count']))) = 0); END; OTHERWISE : RETURN (UNKNOWN); END_CASE; regards,
Tim
From: Rob Bodington [mailto:rob.bodington@eurostep.com]
Sent: 31 May 2006 03:11 To: 'Tim Turner'; peter.bergstrom@eurostep.com; 'Hendrix, Thomas E' Cc: plcs-dex@lists.oasis-open.org Subject: RE: [plcs-dex] RE: Capability property value ranges Yes they do need to be valid - but - they are actually the result of an extended select. So if we have a problem with the rules, then we need to revisit the population of the select.
Regards -------------------------------------------
-----Original
Message-----
The rules are only in the longform - yes - so then they're in the schema & when pulled into a DEX they need to be validated against, right? Or are you suggesting we /IGNORE them?
Maybe I missed something here, but I think if we're generating templates that produce instantiation patterns, then the resulting instances should be a valid population of the EXPRESS model. Else I think we will just move that problem for others to deal with later on.
regards, Tim
From: Rob Bodington
[mailto:rob.bodington@eurostep.com] The rules you mention Tim, are only present in the long form and are produced by the SHTOLO algorithm to determine the population of a select type
Regards ------------------------------------------- -----Original
Message-----
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] 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:peter.bergstrom@eurostep.com] 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 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
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 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]