Page tree
Compiled Professional Profile Comments
NumberCommentsSubmitterSubstantive?Staff recommendationWorking Group RecommendationStandards Committee Decision
1Under the “Member Information” element information, “ModifiedDate” appears twice, on page 16 and page 18 of the document. AAMCnodelete duplicateagree
2Under the “FacultyAppointment” element information, “TenureStatus” is designated as 0 or 1 multiplicity, yet the description says that tenure status may be repeated: “The TenureStatus element may be repeated to describe a progression in tenure status related to this appointment. If more than one tenure status is specified, list the current tenure status first.” This indicates a 0 to many multiplicity would be required.AAMCnocorrect multiplicityagree
3Should there be a full list of other referenced works -- XML, XSD, Medbiq XML guidelines, ... All references should be to a specific version of the specification. -->Add missing references.Daniel RehaknoAdd references to MedBiquitous XML Guidelines, Name Specification 1.0, Address Specification 1.0, Extensible Customer Information Language, Universal Business Language, ISO 3166, HR-XML Person Name Schemaagree
4Technical: Where is it defined that the data types (duration, date) are the XML Schema types and not custom types.-->Define that these are XML data types, not local types.Daniel RehaknoClarify in the documentationagree
5Technical: Does email address support full IETF RFC 2822 formatting? X@Y is a subset of the full RFC. -->Minimal change -- Indicate that the profile specification does not support the full IETF email address. -->Alternative, support the full email address format. If someone has an existing application that supports full RFC, they have to change their data to use it with the profile spec.Daniel RehakpossiblyDiscuss within standards committee and working group (if required)Validate as much of the ietf standard as possible.
6Technical:Should there be an accuracy (and other attributes that parallel birthdate) on deceaseddate? -->Add if missing.Daniel RehakyesOriginal working group discussions indicated that privacy attribute was not needed. Add accuracy.Add accuracy and restrictions as optional attributes.
7Technical: The duration example is confusing. 20060415+P10Y is 20160415, but is this inclusive, i.e., the range started at 12:00:01AM on 20060415, it ends at midnight on 20160414, not sometime on 0415. -->Clarify example.Daniel RehaknoClarify in documentationagree. Durations should go from 1 second after midnight until midnight the ending day.
8Technical:If start, end and duration are all specified, is there a requirement that they be semantically consistent. Does an application that processes the schema have to enforce such correctness, i.e., what does it mean to conform to the standard -- XSD syntax only or more? -->Clarify requirements for consistency in dates.Daniel RehakpossiblyCurrently there is no requirement for semantic consistency. Discuss within standards committee as to whether this is necessarySemantic consistency should not be addressed in the specification. Leave it to the application.
9Technical: An entry can have a create date and an expire date, and the entry has an active status. If the current data that I process the XML is > expire date, is there any semantics to indicate that the status is still wrong, or any requirement that the entire member record be tagged as semantically correct on a specific date. Since this is a static XML record, there is no requirement that is be processed when created; it might exist for years before being process or reprocessed. --> Clarify the semantics. Possibly need to add "date of record" to the instance so that the system processing the data knows how to enforce the semanticsDaniel RehakpossiblyCurrently there is no requirement for semantic consistency. Discuss within standards committee as to whether this is necessarySemantic consistency should not be addressed in the specification. It is hard to relate dates to specific statuses. Leave it up to the application. Many licensing entities require you to renew on an inactive status, for example.
10Technical: Do phone numbers conform to ITU E.164? The "-" are informal and not part of the standard. Why is country code split from number and why aren't both just digit strings (or one digit string of 15 or less digits)?-->Fix examples. -->Change to either one or two elements, but both should be all digits.Daniel RehakyesThe phone number does not conform to ITU E.164. The data type was established as a non-null string to allow for formatting variations Discuss within standards committee to determine if change is warranted.Go with the ITU standard. Leave it up to the application to put in dashes for display. Store data as digits. Keep country code as a separate element with 1 to 3 digits. Up to 14 digits can be in the remainder of the phone number.
11Address Specification:Technical: Section 2 says country name "or" code. Other places say "and". "And/Or" should be normative terms. not informal English. All such "ors" should be "ands". -->Change all occurrences.Daniel RehaknoCorrect the specification to read "country name and code."correct