blchoy
commented
4 months ago It may be useful to first outline the main conceptual model and information content required for aerodrome weather forecasts, agreed on it on the conceptual level, and only then dive into the issue of implementing that model using IWXXM.
I think if this works than there is no reason why we cannot pursue in this way. The only question I have is: We labelled TAC METAR, TAC TAF, etc. as "products" and would like to get rid of them when we move into the data-centric world of SWIM. If we are working on an aerodrome weather forecast aren't we working on another "product"? Or shall we take a look at what data-centric actually means in the aerodrome weather forecast information service first?
From iwxxm-sx created by ilkkarinne: blchoy/iwxxm-sx#4
It may be useful to first outline the main conceptual model and information content required for aerodrome weather forecasts, agreed on it on the conceptual level, and only then dive into the issue of implementing that model using IWXXM.
It seems to me like the current IWXXM-sx draft UML model and its XML Schema implementation is intentionally very generic and uses a lot of soft typing: instead of implementing concepts as UML classes it reuses generic classes/XML elements and forces structure and content on the instance level by constraints and schematron rules.
I have no objection to this approach, but the generic nature of the IWXXM-sx model makes it more difficult to express the new ideas in UML. For this purpose I'm suggesting we start with a conceptual level UML model for the aerodrome weather forecast using interfaces rather than feature classes and then map that into the generic MeteorologicalFeature and other classes of the IWXXM model .