Problem with multiple schemas

[3reality-wangzhijie]

https://github.com/3reality-wangzhijie/commsdsl-min-demo-for-bug

commsdsl2comms -s --warn-as-err -o out/gen ./prot2.xml ./prot1.xml prot2.1.xml

prot2 and prot1 define two separate schemas. prot2.1.xml references the global fields defined in prot1.
When the input files are provided in the above order, the generated read method of variant U contains an issue:

template <typename TIter>
comms::ErrorStatus read(TIter& iter, std::size_t len)
{
    reset();
    using CommonKeyField=
        comms::field::IntValue<
            ::field::FieldBase<>,
            std::uint8_t,
            comms::option::def::FailOnInvalid<>,
            comms::option::def::FixedValue
        >;
....

The main namespace in its KEY_FIELD_TYPE is missing. I attempted to debug this issue, but the codebase is quite complex and I haven't been able to trace through it for the time being.
Changing the input order generates the correct code:

commsdsl2comms -s --warn-as-err -o out/gen  ./prot1.xml ./prot2.xml prot2.1.xml

However, this causes prot2 to become the main schema, while my intended behavior is for prot1 to be the main schema.

[arobenko]

Thanks for the report. The multi-schema support is one of the least used features of the CommsChampion Ecosystem and unfortunately tested less thoroughly than others. The inner architecture of the code generators have some limitations not allowing referencing the elements of the schema (as entity, not particular xml file) that encountered later from the schema that encountered earlier. In this particular case "Prot2" is encountered earlier then "Prot1", and trying to reference elements from "Prot1" in "Prot2" leads to incorrect code generation. I'll try to introduce extra checks and will fail the code generation if such scenario is encountered in the future release.

The inner code generation stages are:

• Parse schema files in the specify order and create the inner XML entities representation tree. In this case the list of schemas trees are: Prot2, Prot1
• Do extra path on the prepared XML entities tree and prepare inner data structures for the code generation. In this case it goes through "Prot2", then "Prot1". When "Prot2" tries to gen info from "Prot1" elements the latter is not ready yet.
• Do extra path on the schemas for the actual code generation.

The whole idea of the multi-schema support is to allow common fields reuse between different protocols, not to do some crazy things of inter-schema references. When listing xml files for parsing, first there should be a schema with common fields, followed by the actual protocol schema. Also the last encountered distinct schema name (last in the list of XML trees), makes that schema to be an actual protocol. That's why ./prot1.xml ./prot2.xml prot2.1.xml sequence generates code that compiles but makes the "Prot2" to be an actual protocol. If you want "Prot1" to be your protocol, then define a common field in "Prot2" and reference it from "Prot1" and also put "./prot1.xml" last in your list.

[3reality-wangzhijie]

Thank you for your detailed explanation. I’ll adjust my approach to writing the schema file accordingly.

[arobenko]

The v8.0 now explicitly checks and disallows such a reference where elements of the schema encountered earlier reference elements in schema encountered later.