search

economidis-nick / createXSDforxMCF

2 stars 2 forks source link

Update Examples for using `<appdata/>` with own XML Name Space #73

Closed DrCaFr closed 2 years ago

DrCaFr commented 3 years ago

The standards spec (Word file) contains several examples where <appdata/> is used with an own XML name space: 

    <appdata>
        <MEDINA xmlns="http://servicenet.t-systems.com/medina/xMCF">
    ...

Since all examples addressing name spaces need to be updated to χMCF version 3.1.1 and it is assumed that MEDINA will not follow this evolution, new examples are needed.

Follows the list of examples and example files:

DrCaFr commented 3 years ago

@TimGuirguis provided an example of <appdata/> usage by Hyperworks — however without an own XML name space:
20211105_1236_xMCF - APPDATA Block Example.zip

DrCaFr commented 3 years ago

The MEDINA examples mentioned above comply to attached XML schema mcf_MEDINA.zip.

TimGuirguis commented 3 years ago

@DrCaFr would you expect a namespace/header per instance of the specific app data within the xMCF?

DrCaFr commented 3 years ago

@DrCaFr would you expect a namespace/header per instance of the specific app data within the xMCF?

Hi @TimGuirguis, the intention of the examples mentioned above actually is to demonstrate, how a tool specific XML schema can be used for the tool specific <appdata/> element. — This by means of a tools specific name space.

Thus, the example you provided cannot replace the existing example. It could serve as an additional example for use of <appdata/> without an additional schema, though.

By the way: I noticed that your example contains <HYPERMESH/> in "all-caps". The Word file uses "camel-caps" <HyperMesh/>. We could & should adjust sect. 7.2.1 & table 3 accordingly, if you agree.

Best regards

TimGuirguis commented 3 years ago

Hi @DrCaFr,

I'm happy for the definition to change from "camel-case" to "all-caps" for those sections.

My understanding on what a namespace per Connection Group means for the current Medina example, is that each block is independent from the next block. Is this correct?

In the example I have provided, Hypermesh is treating every block as the same xml. This is because we have common data shared within an block in the file but outside of the Connection Group definition.

DrCaFr commented 3 years ago

I'm happy for the definition to change from "camel-case" to "all-caps" for those sections.

Implemented with commit a74a9f5.

DrCaFr commented 3 years ago

My understanding on what a namespace per Connection Group means for the current Medina example, is that each block is independent from the next block. Is this correct?

Syntactically yes. Semantically not completely: Properties for connections would be defined on global level (see "Example A (<appdata/> for MEDINA at root level)" on page 12), which then could be referenced by several connections via <appdata/> on connection level (see "Example B", same page). For other use cases, <appdata/> may also/additionally reside on connection group level.
This is explained in first paragraph od sec. 7.2.1.

In the example I have provided, Hypermesh is treating every block as the same xml. This is because we have common data shared within an block in the file but outside of the Connection Group definition.

I understand. MEDINA solved this by using the same schema, hence the same name space, but with different elements on 1st level below <MEDINA/> element: <data_at_root/> and <data_at_connector/>.
Another option would be of course to use different / several schemas / name spaces.

mweinert611 commented 2 years ago

Team decided not to change the example. Text changes were incorporated.