[Platforms] Code definitions (ICES Q1/Q2)

[Roy Lowry]

Dear All,

Starting a new thread.  Basically, we're trying to decide on two things for the future ICES code management system.

(1) Criteria for new code allocation
(2) The syntax for the XML snippet we're using as a code definition.

(1) is absolutely critical and being discussed under a separate thread, initially looking at names.

The first two questions from ICES boil down to the definition schema. Stabilising this through agreement and even considering formalising it as an XML document that may be validated would be useful.  The schema would define the attributes that have their own elements with all other information dumped into the <notes> plaintext bucket.

To me Q1 boils down to "do we need 'previous' fields in the definition' or can we depend on an API allowing us to mine provenance information from a codes-related database at ICES.  From my experience, most operational users will maintain local synchronised copies of vocabularies even when served they are served live and this mode of working would be better supported if the provenance is included in the definition XML.  On this basis I would reject Q1, but note that this should not affect how ICES store the provenance information or that definition attributes should be the only way the provenance information is served.

Q2 is an example of something that may happen more and more.  As we've improved the ship metadata standard over the past couple of years 'length' has developed as an attribute that appeared more and more frequently in the dreaded <notes> section.  It's very useful for differentiating hulls that don't qualify for IMO so seemed to deserve its own element to make it more accessible by parsing the definition.  I can see this happening again in the future, which means our attribute list could well evolve.  This has implications for the design of future versions of the code management system, which currently has a hard-coded attribute list.

Cheers, Roy.