Groups - DRAFT-09-28-10-Minutes-IF-Subcommittee-DRAFT.doc (DRAFT-09-28-10-Minutes-IF-Subcommittee.doc) uploaded

[jeff.waters@navy.mil]

Please review these minutes of the IF subcommittee from September 28, 2010
in preparation for approval at our meeting today, subject to any specified
changes. Thanks.

 -- Jeff Waters

The document named DRAFT-09-28-10-Minutes-IF-Subcommittee-DRAFT.doc
(DRAFT-09-28-10-Minutes-IF-Subcommittee.doc) has been submitted by Jeff
Waters to the EM Infrastructure Framework SC document repository.

Document 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.)


View Document Details:
http://www.oasis-open.org/committees/document.php?document_id=39660

Download Document:  
http://www.oasis-open.org/committees/download.php/39660/DRAFT-09-28-10-Minutes-IF-Subcommittee.doc


PLEASE NOTE:  If the above links do not work for you, your email application
may be breaking the link into two pieces.  You may be able to copy and paste
the entire link address into the address field of your web browser.

-OASIS Open Administration