Top level keys changed?

[jschlyter]

In the schema we've the following top level keys until now and propose we keep them unless there are really good reasons for changing them at this late hour.

• v (version)
• dgcid
• sub (subject, with names etc)
• vac
• tst
• rec

[chris2286266]

thx, @jschlyter this is also our (AT) view

[jschlyter]

@dirkx @gabywh Are there any strict requirements on the naming or can we revert to vac/tst/rec/sub and reintroduce v for version?

[dirkx]

None that I can see. Arbitrary - lets just change them. @kruzikh agree ?

[gabywh]

As discussed: the short names are simply a side-effect of parallel development hcert-schema and here. The short names here are now the ones that passed review within eHealthNetwork and are in the official documentation, so I'd be inclined to leave them as-is.

Schema versioning: separate issue and yes, we should. However, I left it out of consideration for now as:

1. enough work to do already in just getting the schema consistent with regulations and ready for publication, and
2. we now have four separate components (or seven, if you count the generated lookup tables). One option is to simply apply the same schema version to all files but that has the disadvantage that if any one file changes, all files need to change so we lose something of the separation of concerns, which prompts me to consider having independent schema versions for each file in itself, which makes more sense if you consider each file is actually an independent schema

[jschlyter]

Let's discuss the schema version in #4

Regarding the other names, I strongly recommend we change them if possible. If not to drop the single letter ones from the top level. I can live without the sub object though.

[jschlyter]

As @gabywh wrote, we're only working on behalf of the semantic working group. I'm closing this issue and hope that we can move forward with implementations.

[rho-sk]

For practical use in national deployment (NHIC SK), I join the requirement of keeping "sub", it was invented well, and it solves us by reference-consistent maintenance of identification of subjects together with other data (because they are digitally signed and together). At the same time, we plan to use this information to directly identify the certificate holder with his issued certificate.

[gabywh]

Id: you have only name and dob as per the proposed EU legislation. How does moving its location from root to a sub-level change anything? All the other groups can be repeating groups, this one not. It is valid across all three potentially repeating groups. Moving it out of root loses this information.

[jschlyter]

@gabywh One could argue that having sub could move all subject properties into one object, and that that object would be allowed to hold other identifiers. However, since the EU legislation does not allow for that I think that argument is moot. Let's be done with this and move forward!

[gabywh]

However, since the EU legislation does not allow for that

... being the key point.

Closing.