OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

legalxml-courtfiling message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: ECF 5: nc:CaseTrackingID and xx:CaseNumberText Break-Out Meeting


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:

  1. nc:CaseTrackingID is singularly used by certain implementers to uniquely identify CRMDE case numbers.
  2. nc:CaseTrackingID is used by certain implementers as one of several values contained in case submissions and GetCase request/response transactions to uniquely identify CRMDE case numbers (e.g., Case Court Organization ID, Case General Category, Case Category, Case Subcategory, and Case Tracking ID)
  3. Both implementer approaches produce their intended results.
  4. Certain ECF TC members argue that only one element, nc:CaseTrackingID or xx:CaseNumberText, should be adopted in ECF 5.0.
    1. Min/Max Occurs = 1.
    2. FAMDE obtains a unique canonical data value from the FRMDE EFM or CRMDE that uniquely identifies a court case.
  5. Certain ECF TC members argue that nc:CaseTrackingID can be used to contain:
    1. The FRMDE EFM or CRMDE supplied unique canonical data “value” to uniquely identify a court case; OR
    2. The case number, which combined with other elements also guarantee court case uniqueness.
  6. Certain ECF TC members suggested that both elements could be adopted in ECF 5.0.
    1. The ECF TC must specifically define the singular purpose, in written form, of each element. (schema conformance is implied)
    2. Each element’s cardinality could differ to support various use case scenarios.  Example:

                                                               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.

    1. Implementers could use one or both elements.

                                                               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.

  1. Certain ECF TC members suggested that adopting one element with a singular use serves as an incentive for all implementers to be good business partners.
  2. Certain ECF TC members reported that requiring all systems associated with e-filing to conform so a singular specification is a bridge too far for many organizations that may lack the funds to become good business partners.

 

Options:

  1. Use nc:CaseTrackingID or xx:CaseNumberText, but not both, and use it to:
    1. Represent an FRMDE EFM or CRMDE-supplied canonical data “value” that uniquely identifies a specific court case; OR
    2. Represent a case number.
  2. Use nc:CaseTrackingID or xx:CaseNumberText, but not both, and use it to:
    1. Represent an FRMDE EFM or CRMDE supplied unique canonical data “value” that uniquely identifies a court case; AND
    2. Represent a case number.
  3. Use one element, nc:CaseTrackingID or xx:CaseNumberText, and set:
    1. Min Occurs = 1; and
    2. Max Occurs = 1.
  4. Use one element, nc:CaseTrackingID or xx:CaseNumberText, and set:
    1. Min Occurs = 1; and
    2. Max Occurs = Unbounded.
  5. Use both nc:CaseTrackingID and xx:CaseNumberText, where each is used for a specifically-defined purpose, and set the cardinality constraints for both elements to:
    1. Min Occurs = 1; and
    2. Max Occurs = 1.
  6. Use both nc:CaseTrackingID and xx:CaseNumberText, where each is used for a specifically-defined purpose, and set the cardinality constraints as follows:
    1. Min Occurs = 1 and Max Occurs = 1 for one element; and
    2. Min Occurs = 1 and Max Occurs = Unbounded for the other element.

 

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]