Document:
DRAFT-09-14-10-Minutes-IF-Subcommittee

Draft (A preliminary unapproved sketch, outline, or version.)

Details

Submitted By Jeff Waters on 2010-09-15 6:58 am UTC

Publication Type

None at this time.

Group / Folder

EM Infrastructure Framework SC / Resources

Modified by

Not modified.

Copy

This document is not a copy.

Technical Contact

None at this time.

Download Count

175

Download Agreement

None at this time.

Description

At today’s meeting, the group reviewed and discussed the following edits as specified by item number (column A) in the DE Issues spreadsheet, version 6 (see Reference 1 below) :

Items Covered from Issues List:

TOPIC: geo-oasis:Where – What is the status and how do we help advance the effort? (Answer:-- OGC will be moving forward with to develop the geo-oasis:Where profile, based on latest email from Carl. Motion approved to recommend Don McGarry be a liaison to the OGC committee which will generate the geo-oasis:Where profile since Mitre is a member of OGC. The need for simplicity was discussed and OGC specifications like geoRSS were recommended in this vein as good examples for consideration. )

ITEM (10) TOPIC: geo-oasis:Where – Can we approve the edit to remove the reply/to and error/to and the associated AuthenticationType that were previously proposed as additions to the DE because this capability will be addressed by other routing standards? (Answer:-- Yes, subject to fixing a comment in the issues spreadsheet to change “transport level security” to simply “transport level”. Some discussion was raised about whether a component like this should be allowed to be present and optional. The advantages include that systems that can support it can use it and others can ignore. The disadvantages include that parsers still have to account for this potentially being present, that more work is needed and implied if we include these items, and components which are for certain systems may not be appropriate for an open standard. Although the discussion was noted, the consensus was that the issue was resolved at the face-2-face and the edit was approved. )

ITEM (11) Language – Can we approve the edit to change the type of this element from “xsd:string” to “xsd:language”? (Answer:-- Yes, the goal is to support more than 2-character language codes and to go with the best practice found in http://www.ietf.org/rfc/rfc3066.txt which is what is supported by XMLSchema with their “xsd:language” type. )

ITEM (12) DistributionRef – Do we agree to leave this as a “red” item for further discussion after all edits and Jacob’s recommendations for reorganizing the DE are considered? (Answer:-- Yes, the issue of whether to restrict and better define the comma-delimited id based on component parts will be revisited later. )

ITEM (13) and Item (14) targetArea & Point object -- Do we agree that we should wait for OGC to produce the geo-oasis:Where profile to address this item? (Answer: Yes. geoRSS was discussed as a potential format option, although it was suggested that it may not satisfy all of our requirements. We also determined that probably only items 13 and 14 should remain color-coded yellow awaiting geo-oasis:Where, the other items currently color-coded yellow will be changed to grey because they can be handled like any of the other issues, they are not dependent on the geo-oasis:Where. )

ITEM (15): Specifying targetArea Preference - Should we specify preferred target area explicitly or implicitly by order of the xml elements? (Answer: Still discussing. Suggestion was to handle preference by order of the xml targetArea elements or subelements (circle, polygon, etc.); however some concern was expressed about the potential added parsing difficulty if not using the XMLSchema “sequence” to specify a default order. We’ll pick up this discussion here with this item next time. )