Document:
DRAFT-08-02-11-Minutes-IF-Subcommittee.doc

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

Details

Submitted By Jeff Waters on 2011-08-02 8:40 pm 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

158

Download Agreement

None at this time.

Description

At the August 8th, 2011 meeting of the Infrastructure Framework subcommittee, the members' discussions included the following topics:


1. TOPIC: Can we recommend that latest drafts of common components be posted to a common folder so everyone can find them? (Answer: Yes, the recommendation is that the drafts be posted to the RIM Common Types / Candidate Common Types folder and that any posting be shared with the EM TC as a whole. )

2. TOPIC: Should we jumpstart the addition of new common type elements to include <estimate> and <remark> and perhaps <priority> and <confidence>? (Answer: Yes, the normal process would begin with an email to RIM for new items, and then a review by RIM, with a prototype format and recommendation to EM TC with a week to review and approval; however, these two items are already in Sitreps and it is felt that we don’t want to hold up Sitreps so we’ll streamline entry of these two items. )

3. TOPIC: Under our current naming conventions, do we end all xml type names with “Type” and for xml element names, we should replace any use of “Type” with “Kind”? (Answer: Yes, to avoid confusion, the word “Type” will be limited to xml type names. The word “Kind” will be used as needed in xml element names. )

4. TOPIC: A number of small issues were addressed to help guide the drafting of the next version of the DE 2.0 working draft. (a) Let’s continue to use “List and Associated Values” for ValueListURI type elements; (b) Reference and don’t duplicate data dictionary entries from the common components; (c) Fix the DistributionReference so that all elements of the structure are mandatory; (d) an Appendix A Best Practices would be useful for our larger specs where common components are referenced in the data dictionary, but they could be explained informally and demonstrated in the non-normative Appendix A.