Thanks to @brlcad and @TRThurman for their input on this issue!

[Tom]
I posted a formal bug against 2nd edition ap203 for the missing PRODUCT_CATEGORY_RELATIONSHIP.
See http://www.wikistep.org/bugzilla/show_bug.cgi?id=5406 for the actual declarations to add.

[Sean]
I have a vague recollection of encountering that bug several years ago, but did not report it upstream. Indeed, the version of ap203e2 checked into STEPcode (ap203e2_mim_lf.exp) does not include any reference to PRODUCT_CATEGORY_RELATIONSHIP and this matches the STEPtools version from here:
http://www.steptools.com/support/stdev_docs/express/ap203e2/wg3n2635_ap203e2_aim_lf.exp

That could explain some of our difficulties getting AP203e2 to work in BRL-CAD’s geometry importer…
Looks like mpictor ran across the issue too: #68

I would recommend that the STEPcode project test the addition to identify any induced issues.

Is there a version of the schema with the change added available somewhere (or could it be made available somewhere)?

[Tom]
At this time, there is no formally released update.
Unfortunately AP 203 was withdrawn under the assumption that AP 242 would be a drop-in replacement but the significant schema architectural issues were not identified.

Problems:

WG12 did not consider the part 21 requirement for the file_schema entry in the part 21 header and did not include the AP 203 schema name in the allowed file_schema entries.

It is also true that WG12 did not formally recognize the different use cases of pre-processors and post-processors in the documentation (which would have lead to separate
instructions for file_name contents for pre-processors and for post-processors.)
part 21 at least supports multiple schema names, not that that helps much.

The long form schemas all have multiple entries of their schema names instead of a single reference with pointers elsewhere.

What should STEPcode team do?

patch your copy of 203e2. A fix from WG12 will take a while.

For pre-processor change the version id to an integer representing the date of the patch: 20150201 for example. It will still be an INTEGER.

For post-processor, allow that value in addition to whatever versions you support.

raise the issue with the CAX-IF, citing the bug number mentioned, and build a consensus with them on what to do.

raise the issue with Keith Hunten the convener of WG12. He is already copied on the relevant bug but it never hurts to have direct customer input.

The snippet in the bug report also noticeably uses the acyclic_product_category_relationship() function definition defined in AP214, and not the version in the original AP203 — is that intentional? Similar implementations, but there are some subtle changes (e.g., logical to boolean).

Sean, regarding the 'acyclic' function: At some point in time (could not find history in bugzilla relevant to this change from LOGICAL to BOOLEAN),
we noticed that a FUNCTION returning a 'UNKNOWN' value causes the RULE to pass.

For the acyclic rules, we decided to prohibit that possibility. As I looked at the function, it seems there is no way to escape the function without having
the value set to either TRUE or FALSE.

ap203e2 missing PRODUCT_CATEGORY_RELATIONSHIP #305

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions