[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: ECF 5: nc:CaseTrackingID and xx:CaseNumberText Break-Out Meeting
All: Jim, thanks for the wonderful summary and notes. Brain will be at the meeting tomorrow. I have a conflict. We would vote for option 6, where: 1. xx:CaseNumberText is required with max = 1, defined as the primary case identifier known to the *public* (i.e., the text that would appear on the face of a filed document in the caption). 1.1. No objections with cardinality set to unbounded for scenarios such as “consolidated cases, transferred cases, appealed cases” provided that there is an associated attribute/element that describes the meaning of the additional
xx:CaseNumberText, the primary xx:CaseNumberText is marked as the primary, and other case numbers are or were at one time *public* (i.e., the text that would appear,
or appeared, on the face of a filed document in the caption). 2. nc:CaseTrackingID is required with max = unbounded, defined as any unique *internal* identifier used by a MDE, appropriately defined by the system using it.
2.1. If no such *internal* identifier exists, then this element must be populated by the *public* case number. 3. Both of these elements should/must exist in all messages where nc:CaseTrackingID currently exists. 4. We also think systems should not have to call GetCaseList to get internal identifiers used to seed GetCase. It should be possible to call GetCase directly using
xx:CaseNumberText. If this requires associated policy data (System Identifier, Location, Case Category, Case Type) to disambiguate case numbers then that’s fine/good.
5. Finally, GetCaseList should be queryable using wildcards and partial
xx:CaseNumberText values with limits on the number of values returned. Thanks, Todd From: legalxml-courtfiling@lists.oasis-open.org [mailto:legalxml-courtfiling@lists.oasis-open.org]
On Behalf Of Price, Jim ECF TC Members: This email is intended for the task team that agreed to meet tomorrow, Tuesday January 23, 2018, to discuss the value of adopting nc:CaseTrackingID and/or
xx:CaseNumberText to uniquely identify CRMDE case numbers. Since I am not be able to attend the meeting, I request that my feedback below be taken into consideration by the task team. Thanks in advance for your time and consideration, Jim >>>>>>>>>>>>>>>>>>>>>> Major Facts:
i. nc:CaseTrackingID (Min Occurs = 1, Max Occurs = 1)
ii. xx:CaseNumberText (Min Occurs = 1, Max Occurs = 1 or Unbounded) NOTE: Cases may be associated with one or more “case numbers” (e.g.,
consolidated cases, transferred cases, appealed cases, law enforcement case tracking IDs in criminal cases, etc.), which is why Max Occurs = Unbounded is suggested.
i. Normative: If an implementer requires both elements, they are available for use provided that the implementation of each element conforms to the written specification. (schema
conformance is implied)
ii. Non-Normative: If an implementer requires only one of the elements, both elements can be populated with the same values. This approach introduces very little overhead.
Options:
Recommendation: My preference is either options 1 and 4, or option 6. Both approaches provide implementers the flexibility they require to uniquely identify a court case, either as a single canonical data value or as part of a combined value to achieve the same outcome. Based on prior conversations among
the ECF TC members, nc:CaseTrackingID is being used today by different implementers to represent a single canonical data value of a court case or just a case number. Additionally, the cardinality constraint of Min Occurs = 1 and Max Occurs = Unbounded allows all implementers the flexibility they require for a given court and case type. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]