[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, (all)
sorry for the delay in response - I am now tasked on other
things.
I have researched what the original problem was and why
there was a need to manage documents separately from the other properties - so
hopefully we will be able to move ahead on this issue.
Product properties are applied through the product_view_definition entity, as shown within C076 assigning_product_properties.
However, in the DIS version of AP239, the
Document_definition entity was not part of the subtype hierarchy for
product_view_definition. This is the main reason, as I understand it, a separate
capability had to be created to describe how to assign properties to documents.
Hence capability C087 - assigning_document_properties
was created and introduced the other document specific property representations
(descriptive_document_property & numerical_document_property). This
capability links with C005 - Representing documents where the old hierarchy is
still visible - see Fig 3 and described in the section on document_definition
below Fig 5.
The benefit of the model is that it enforces the
associations between the types of document properties (above) and the products
to which they should be associated with (i.e. types of files or
document_definitions). Reference data would need to be developed along with the
relevant templates to complete this. There are also rules where specific
combinations of various values which are enforced (I'll discuss this later), for
which reference data would also need to be
addressed.
However, it is now possible to associate general
properties to document_definitions and files without recourse to those specific
entities above, because in the IS version of AP239, Document_definition is a
subtype of product_view_definition. This needs to be reflected in
C005.
As the model now stands, either approach is possible,
including a mixture which does not help implementers decide how to code for the
differences in the model. In general the model is presently able to be abused
and even circular in the assignments which seem possible (e.g. through
document_assignment I can now assign a document_version to another
document_version which seems rather clumsy.!).
Not all of the rules and constraints are documented in
the capabilities. In particular (hinted at earlier),
Document_property_representation has a function 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.
In general, I am probably more in
favour of keeping a tighter spec/model than a more relaxed and generic solution
because of the possible downstream mis-use. By removing C087 in favour
of the generic model for product properties we will lose the documentation
of that part of the model while we still do not remove the document proprty
entities from the AP239 schema. However, removing the capability would restrict
relevant DEXs to only use the generic mechanism. This may lead to
inconsistencies in representations across data wharehouse and exchange file
implementations.
I think what we may gain in a
generic template we may lose in wider interoperability and increased
processor coding.
From what I understand C076 caters
for the general product property model which thererfore, covers assigning
general properties to document_definitions & is reflected in the template
design.
I would like to hear from others
whether there is any other feeling regarding removal of the document property
model as I see no harm in keeping it & refining a C076 template for it when
required. It may even help to separate out some of the reference data in this
area. However, I am open to more informed
persuasion.
regards,
Tim
From: Peter Bergström [mailto:peter.bergstrom@eurostep.com] Sent: 25 May 2006 03:30 To: 'Tim Turner'; 'Hendrix, Thomas E' Cc: plcs-dex@lists.oasis-open.org Subject: RE: [plcs-dex] RE: Capability property value ranges OK, so the rule was OK,
and we _could_ use document
properties. But why not use product
properties as they are instead? A document is a product, and there is nothing in
the product properties as they are now that is illegal for documents - since
they are products, right? So I don't understand what you say we have to prune
out unnecessary items, and have to ensure that we don't allow for any illegal
associations? [Tim Turner
Replies:] If we allow usage of the document
property model (specifically those mentioned above) then we would need to
ensure that the many constraints & rules are respected in the template
parameter options and allowable reference
data. To a
document_definition or a subtype of file, you may assign Assigned_property, in
which case you are using product properties _as they are_.[Tim Turner Replies:] There may be other
properties you may wish to assign to a document which may not be specific
to documents - such as colour, weight, location
etc.. You may also assign a
Assigned_document_property, and then you branch off into the document specific
properties which are similar to the product properties _but not the same_.[Tim Turner Replies:] Yup,
and I guess that these allow for properties that may be specific to documents
e.g. number of pages, chapters, page size etc.,
Why would we ever use document_properties that are specific?[Tim Turner Replies:] Presumably so that properties specific to documents are only allowed to be applied to documents or files. E.g. an electronic file may have a size property of 1 MB (this would make no sense if applied to something else other than a document/file. In addition I think the model alows us to place further rules (within a DEX for example) to constrain certain associations. However, I think these points may be compensated through careful reference data structuring.
Peter From: Tim
Turner [mailto:tjt@lsc.co.uk] 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: 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
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]