Create a block macro to render table of a class in plateau

[kwkwan]

The table should show:

• its owned attributes
• its super class
• owned attributes of super class
• loop super class to get its super class till it is topmost
• owned attributes of these super classes

[kwkwan]

Refer to table in 4.18.3.1.1 dem:ReliefFeature (Plateau document 001-v4)

[ronaldtse]

@kwkwan can we loop till we get to the top superclass?

[kwkwan]

@kwkwan can we loop till we get to the top superclass?

@ronaldtse Yes, it will.

[ReesePlews]

hello @kwkwan thanks for the work on the lutaml gml dictionary tool, it is working well.

regarding the example table, shown below

Refer to table in 4.18.3.1.1 dem:ReliefFeature (Plateau document 001-v4)

is it possible to use a different table (shown below) for the initial test? doc001-v4 - document page 58, pdf page 69. 4.2.3 建築物の応用スキーマ文書 Building （CityGML） bldg:Building

i have prepared the most content (EA "Notes" property) for that subpackage tables. thank you.

happy to test these updates when you are ready. just let me know. thanks!

[kwkwan]

hello @kwkwan thanks for the work on the lutaml gml dictionary tool, it is working well.

regarding the example table, shown below

Refer to table in 4.18.3.1.1 dem:ReliefFeature (Plateau document 001-v4)

is it possible to use a different table (shown below) for the initial test? doc001-v4 - document page 58, pdf page 69. 4.2.3 建築物の応用スキーマ文書 Building （CityGML） bldg:Building

i have prepared the most content (EA "Notes" property) for that subpackage tables. thank you.

happy to test these updates when you are ready. just let me know. thanks!

OK. I will switch the initial test to this example.

[kwkwan]

During the test with the example (4.2.3 bldg:Building) and xmi file plateau_uml_20240708_all_packages_export.xmi, I can retrieve the following properties in 継承する関連役割:

lod0RoofEdge
address
boundedBy
lod2Solid
lod4Solid
lod1Solid
lod3Solid
bldg::lod2MultiSurface
lod0FootPrint
lod4MultiSurface
bldg::lod3MultiSurface
bldgDmAttribute
bldgDataQualityAttribute
largeCustomerFacilityAttribute
consistsOfBuildingPart
bldgDisasterRiskAttribute
ifcBuildingAttribute
bldgFacilityAttribute
bldgFacilityIdAttribute
bldgRealEstateIDAttribute
outerBuildingInstallation
bldgUsecaseAttribute
bldgKeyValuePairAttribute
buildingDetailAttribute
interiorRoom
indoorBuildingAttribute
buildingIDAttribute
bldgFacilityTypeAttribute
interiorBuildingInstallation

A property named bldgUsecaseAttribute is found but not in the PDF. Is it correct to show it?

[ReesePlews]

hello @kwkwan since these tables in the document are "model driven" i think we should always show the content from the model, as it may have been mistakenly left off in the PDF (because they were manually created). i think @ronaldtse would agree with this understanding.

[ReesePlews]

hello again @kwkwan if i wanted to confirm the version (date) of the XMI file, where should i look? want to make sure you have the newest version.

[kwkwan]

I download the xmi file plateau_uml_20240708_all_packages_export.xmi on 12 July 2014. The size of it is 10.6 MB.

[ReesePlews]

there is a newer version, how can i get that to you?

[ronaldtse]

I have just uploaded it to this commit:

• https://github.com/metanorma/mn-samples-plateau/pull/114/commits/6a041dcdb50ef48aad620d7addcb646f52ae27fd

It is located in this PR:

• https://github.com/metanorma/mn-samples-plateau/pull/114

@kwkwan can you try with the newly exported XMI file? It seems to contain additional GML content.

[ReesePlews]

thanks @ronaldtse

[ReesePlews]

@kwkwan if you have any questions about the new version, please let me know. the structure has changed, with the figures now inside of the individual folders, instead of outside.

[kwkwan]

When generating the table for class. some attributes shown in PDF are still missing in the new macro. It is because I cannot find out the logic to get these attributes from Building.

These are:

• attributes: gml and core in 継承する属性
• associations: gen in 継承する関連役割

@ronaldtse Do you have any cues to link up the these attributes with Building?

[ReesePlews]

hello @kwkwan because the UML tables in doc01 were made manually, there are attributes which are not readily accessible (through the model), in my understanding. the inherited attribute cells that are "gray" in color were manually added to those tables and are not in the individual models. are those the attributes you are mentioning?

@ronaldtse and i have discussed with the client, and at this time, we can leave out the attributes from the gray cells if they are not already linked in the UML, unless Ron has directed you to do something different. i am not really the UML expert.

does that help?

[ronaldtse]

@kwkwan can you please post the exact attributes/relationships that are missing and from which class?

[kwkwan]

OK. Here they are.

[ronaldtse]

Update: I did some digging on the 2nd category, with dateAttribute. Unfortunately, I cannot find any connection between Building and dateAttribute in the XMI. They should not exist in the table?

[ReesePlews]

hello @kwkwan looks like you are using the HTML output, please use the PDF, the official file plateau_doc_0001_ver04.pdf from the "reference-docs" folder. it will have gray shaded tables i will paste in here

[ReesePlews]

please see the pdf for the remaining parts of the table

[ronaldtse]

As previously agreed, things that cannot be determined from the model must be dropped.

This includes:

• gray shading and the parentheses because whether an attribute is meant to be used is not shown in the table.

[ReesePlews]

@ronaldtse yes, correct "gray shading" content will not be in the model, and will be dropped. but i dont know why i cannot find gml:description, its not shaded gray.

[ReesePlews]

maybe it comes from gml:feature?

[ronaldtse]

Update: I checked core:terminationDate and core:RelativeToWaterType, both of them do not seem in any way connected to the Building class.

@ReesePlews we need the PLATEAU team's help here, the tables in the PDF seem to be erroneous.

Let me explain terminationDate.

There are 2 terminationDate attributes in the XMI.

• One belongs to the _CityObject UML class in the core package. We want this one.
• One belongs to the DmElement UML class in the "Urban Planning ADE 3.1" package.

The first one is shown here:

            <packagedElement xmi:type="uml:Package" xmi:id="EAPK_9E3ECCD9_5472_45ce_BE7A_BC004A52B63C" name="CityGML2.0">
                <packageImport xmi:type="uml:PackageImport" xmi:id="EAID_B0802E45_AF95_433a_BA7A_93EB62945730" importedPackage="EAPK_939925FF_6235_4286_82FF_7392B33F305C"/>
                <packagedElement xmi:type="uml:Package" xmi:id="EAPK_526A0DDE_1614_4df1_920F_F681125AE7C4" name="core">
                    <packagedElement xmi:type="uml:Class" xmi:id="EAID_60CE61DE_7E88_4e8b_BFED_13500E7DCDEC" name="_CityObject" isAbstract="true">
<!-- ... --> 
                        <ownedAttribute xmi:type="uml:Property" xmi:id="EAID_6008181F_A953_4a0f_9F76_208235B9BC3A" name="terminationDate">
                            <lowerValue xmi:type="uml:LiteralInteger" xmi:id="EAID_LI004199_A953_4a0f_9F76_208235B9BC3A" value="0"/>
                            <upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="EAID_LI004200_A953_4a0f_9F76_208235B9BC3A" value="1"/>
                            <type xmi:idref="EAJava_xs__date"/>
                        </ownedAttribute>

In order for UML classes to "inherit this attribute", they need to have a Generalization relation to "EAID_60CE61DE_7E88_4e8b_BFED_13500E7DCDEC", which is the ID of the abstract class _CityObject.

Classes that inherit from _CityObject in the bldg package are only these:

• _BoundarySurface
• _Opening
• BuildingFurniture
• BuildingInstallation
• IntBuildingInstallation
• Room

i.e. Not from Building.

i.e. This means that Building cannot have this attribute.

[ronaldtse]

maybe it comes from gml:feature?

Yes it is from _Feature:

                <packagedElement xmi:type="uml:Class" xmi:id="EAID_553A3DF9_69B8_4fb4_BF15_EC613B5B74CD" name="_Feature" isAbstract="true">
                    <ownedAttribute xmi:type="uml:Property" xmi:id="EAID_E52C9299_7D96_49e8_B6E1_B81E93B8C25F" name="boundedBy">

This means all classes that inherit from _Feature shall also have this attribute.

However, the only classes that inherit from _Feature (id: EAID_553A3DF9_69B8_4fb4_BF15_EC613B5B74CD) in the XMI are:

• _CityObject
• Address
• Appearance
• _FeatureCollection

i.e. this is "meant to come from _Feature", but there doesn't seem to be any connection between _Feature and the Building class in the model.

[ronaldtse]

@kwkwan can you update the table to show for each inherited attribute/association, from which class it is inherited from? This will help the reader.

[kwkwan]

@ronaldtse Updated tables to show where the attributes come from via commit (84dddd3f574e600f7569b0227417900e822cbf97). Those attributes are all from _AbstractBuilding as no attribute has been defined in Building class.

[ReesePlews]

hello @kwkwan thank you for the code to show the sample.

i have a question about the content which is stored in the EA "Notes Property". when adding content to the components of the model in EA, for "building" i used the model on docpage47, pdf page 58 of the original doc01-v4.pdf ; i have added content to as many components (classes, attributes, roles, etc) as i could.

for "inherited roles" (継承する関連役割) i have added content which should be showing in the "definition" (定義) column of the autogenerated table. in my locally generated version of the document, i am not seeing that content.

(lutaml autogenerated plateau uml table):

however for bldg:lod1Solid (and other inherited roles) i have pasted their content into the "Notes Property"

are you seeing that content in the XMI file or is it missing? perhaps you just have not added that content to the table yet. i just wanted to mention this.

[ronaldtse]

I believe we haven’t added these content to our model. @kwkwan can you please help include them?

[kwkwan]

OK. I will follow up this issue.

[ReesePlews]

thank you for checking that @kwkwan . i noticed something else, the order of the content in the autogenerated tables (attributes, roles, etc) does not seem to match the order of the original table. are you modifying the order, or is it exactly from the XMI file? if the order is exactly from the XMI file, then i need to ask the client where they set the order of the "things" in the model (in EA). sorry i forgot to mention this earlier.

[kwkwan]

OK. I will follow up this issue.

The gem lutaml has been updated to show the definitions from connectors via associations.

[ReesePlews]

thank you very much @kwkwan i will regenerate the document from now.

[kwkwan]

thank you for checking that @kwkwan . i noticed something else, the order of the content in the autogenerated tables (attributes, roles, etc) does not seem to match the order of the original table. are you modifying the order, or is it exactly from the XMI file? if the order is exactly from the XMI file, then i need to ask the client where they set the order of the "things" in the model (in EA). sorry i forgot to mention this earlier.

The order follows the content in XMI file.

[ReesePlews]

The gem lutaml has been updated to show the definitions from connectors via associations.

thank you @kwkwan the 2nd build of the document showed the content for the associations.

[kwkwan]

Discussed with @ronaldtse, attributes are now sorted by name.

[ReesePlews]

hello @kwkwan i have a new version of the model. an abstract class and relationships were missing and have been added. i also have feedback on the table style. how can i send you the model, make a new folder and submit via github desktop?

[kwkwan]

You can submit the the file to the folder reference-docs of the repo mn-sample-plateau via github desktop.

[ReesePlews]

https://github.com/metanorma/mn-samples-plateau/commit/d178776ac6dfc7cdada96638b98547eb3a7b70d6

sorry @kwkwan could not upload to reference-docs; see the note with the commit. thank you.

[kwkwan]

Hi @ReesePlews I have received the file. Thank you.

[ReesePlews]

hello @kwkwan the structure and style of the table looks good. at this time there is one item i wondered if you could adjust, at your convenience.

in the cell on the left, the attribute bldg:roofType (_AbstractBuilding). while the content is a bit different from the original table we like the additional information shown in the ( )s. however the data is shown as one continuous line, i wonder if it is possible to put a carriage return after the initial attribute name. something like this:

bldg:roofType
(_AbstractBuilding)

i think it would be easier to read. if that is a lot of work please discuss with @ronaldtse. thank you.

[kwkwan]

Carriage return has been added after the attribute name.

[ReesePlews]

hello @kwkwan i have checked the carriage returns in the table and they look good. thank you.

i have also updated the model with the content data from the "landuse" classes. that is described here: https://github.com/metanorma/mn-samples-plateau/pull/114/commits/6a3801951b97af352b67e69fe2ae1e414b66b72b

i tried to generate the document locally after adding content for the landuse i am not seeing that data output in the Landuse table. i also updated the first row of the building table with content but it was not shown either.

after checking the xmi output, let me know if you find any problems with that. thank you

[kwkwan]

Hi @ReesePlews Updated the path with the new XMI file. Please check.

[ReesePlews]

hello @kwkwan thank you for updating the model. i have checked the output and i have two questions:

1) in the Landuse model, i added "content" into the "Notes properties" for the attributes after the "⾃⾝に定義された属性" heading (example "areaClassificationType") but that content is not showing in the autogenerated table.

2) in the Building model i added "content" into the "Notes properties" for the _AbstractBuilding class, not only the individual attributes. i was expecting that content to be displayed in the first row of the autogenerated table, in the cell to the right of "型の定義", similar to what is shown on doc01-v4, pg 58, pdf pg69, but that cell is still empty.

i added that new "content" in the building model "Notes property" to test the formatting described in (https://github.com/metanorma/coradoc/issues/125) ; these updates to the building model are the first which actually have an image correctly formatted.

if you could check into these two issues, i will provide feedback to help. thank you.

[ronaldtse]

For the second one, the note on AbstractBuilding will not show up because the table is for Building, not the superclass AbstractBuilding.

The first one may be a bug.

[ReesePlews]

thanks @ronaldtse i also have contents pasted in for the "Building" class which is shown (without attributes) below the Abstract building class, if that information helps. the content is slightly different, but it can be unified. the content in the _Abstract building class would be "more correct" (as it was actually pulled from the static table that was created during the main conversion of the document.)

[ronaldtse]

I'm not sure if I'm confused, but no description for AbstractBuilding would be shown because there is no individual table for AbstractBuilding. A table will only show the description for that class.

[ReesePlews]

hi Ron, i thought bldg::_AbstractBuilding was a class in the model... so that is why i was able to attach "contents" in the "Notes Property" of the bldg::_AbstractBuilding; previously i had only attached the same content to the smaller bldg::Building class

[ronaldtse]

The _AbstractBuilding class is a class but it is not rendered as a table in this document. Therefore no description will show up in this document. This is a design decision of the PLATEAU team to not have individual tables for every class.