Description
At the Infrastructure Framework subcommittee meeting of September 28, 2010, the members proceed to discuss and approve edits addressing the issues list (uploaded separately as an excel spreadsheet version 07). The following edits were addressed at the last meeting:
ITEM (15) TargetArea – If multiple target areas are specified, what should we do? We used to just say they should be unioned, but should we consider having a precedence where one area (e.g. LOCODE) is preferred as a more accurate description than another (e.g. polygon)? (Answer:-- This question was raised at the last meeting on the 21st, but not resolved. Some of the area formats are more about geo-politics, like LOCODE, whereas others are more just geography, such as polygon. So the routing policies implied may be different and trigger different considerations. This item reserved for further discussion next time. )
ITEM (16) Circle Example – The circle example needs to be fixed, everyone agree? (Answer:-- Yes, previously Jeff lumped this with the geo-oasis:Where topics, but Hans correctly noted that we can fix this on our own. Jeff will make the fix and we'll approve next time.)
ITEMS (17) Country, (18) Subdivision, (19) LOCODE – Can we approve the edits to change the type of Country, Subdivision and LOCODE to ValueListURI's? (Answer:-- Yes, these edits are approved. However, there is still the issue to fix the examples. Also should there be defaults for these? )
ITEM (20) COId/refCOId– How best should we implement the face-2-face recommendation to support the need to link content objects? (Answer:-- At the face-2-face, we recognized the need to research this and as of yet, we don't have a recommendation; however, Dave will look into this and make a recommendation next time. Jeff mentioned xlinks as a potential solution. Dave noted that some solutions that work for data-at-rest do not adequately support data-in-motion. Also some solutions that work with a DOM parser (which is easier to process, because the entire xml file is read into memory) don't work well for SAX parsing (which is faster and lower in memory requirements, but more challenging to program, because the xml file is read and processed piece by piece))
ITEM (21) IncidentID, and ITEM (22) Incident Description and ITEM (23) ValueListURI– Are we ok approving that no edit is required for these three items? (Answer:-- Yes, at the face-2-face it was acknowledged that significant constituencies from the original DE work wanted these items left as is, rather than remove them, and that the suggestion to add a new <type> element to the ValueListURI was not appropriate. So no edit is required to maintain them.)
ITEM (24) Confidentiality – Are we ok approving that the type of this item be changed to a ValueListURI? (Answer:-- Yes. Dave will suggest a good way to use this ValueListURI for confidentiality in practice as a sort of profile at one of our upcoming meetings.)
