Parasolid v30的新嵌入式架构格式？

Question

I have two binary Parasolid files from v30 (internal modeller string is 3000226, schema string is SCH_3000226_30000_13006). In it, the embedded schema information for older types is as defined in the latest copy I have of the Parasolid XT Format Reference. However, for entity type 204 (introduced after the 28101 schema) the embedded schema format is completely different. Luckily, it has a lot of strings in it, so it is pretty easy to reverse engineer the basic form of it:

unsigned byte: number of fields
short string: nodename
short string: description

then for each field
  short string: fieldname
  five bytes: maybe somehow correspond to <transmit 1/0> <node class> <n_elements> ?
  byte: (field) type

byte: possibly <variable 1/0> ?

Then the entity proper begins as expected.

The problem is that this seems like a workable parsing of the binary version, but without knowing what the five mystery bytes actually correspond to, I don't know how to implement support for this in a Parasolid text file. It might be two short ints and an unsigned char, might be one 4-byte int and an unsigned char. Heck, since in both examples I have the first three mystery bytes are zero, there might even be a string of some sort in there, which just happens to be 0 length in this case, in which case, of course, it's not really five bytes always but just happens to be five bytes in my two examples.

Does anyone have an idea what is going on in the mystery bytes?

Also, I'm assuming this scheme will be active for entity types 204 and up. What I don't know about is entity type 203. I don't believe I've ever seen a Parasolid file with that type in it.

(Also, does anyone have any insight as to why they would make a non-backward compatible change to a feature intended solely to support backwards compatibility?)

Answer 1

Stumbled onto the answer for own question. It turns out I should have realized they wouldn't make a backwards incompatible change here. In fact what I ran into is documented, just very badly. Here are the rules as I have figured them out:

This "new" form of embedded schema is what you get when you have an entity type which is not present in Schema 13006. (So types 185 and up, I believe.) In that case, the format is

unsigned byte: number of fields
short string: type name (aka nodename)
short string: description

then for each field
    short string: name
    short int: ptr_class
    positive integer: n_elts
    if ptr_class == 0
        short string: type
    if n_elts == 2
        logical: xmt_code

Notes:

• The "for each field" code is the same as the field data incorporated in the insert and append (I and A) codes in the edit sequence version.
• The "positive integer" type in binary is like the pointer index type, where it is 2 bytes if the integer is less than 32767 and 4 bytes otherwise. Since I've never seen a value higher than 2 here, and cannot begin to imagine what sort of entity would have a fixed size and more than 2 to the 15th elements, I haven't implemented this yet.
• Also this n_elts field appears to be one greater than the equivalent n_elements field found in the standard schema. (This is clearly visible in the n_elts == 2 test above -- according to the file format spec, it should be n_elts == 1, but that does NOT work at all.)

Minus my caveats here, these basic instructions do appear in the 2016 version of the file format, on page 14. However, the formatting is completely broken, as can be seen comparing with the older V15 version of the document -- there should be two levels of bullet points, not one, and the first row of the table was mistakenly turned into a header!

I've also got to note that while this has my code working for entity type 204, I appear to have never seen a new type in an X_T file before, which is why I never noticed this hole in my code. So I cannot vouch that this works in the general case -- all I know for sure is it works in the type 204 case.