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: Groups - Action Item "ECF 5.0 - Fix cardinality issues" Modified


Action Item Subject: ECF 5.0 - Fix cardinality issues
Item Number: #0011

Description
Fix cardinality issues. Make CaseCharge optional in some cases. Make Document metadata and rendition in FilingLeadDocuments optional. iii. Provide best practices around cardinality. Consider Green Filing recommendations to make required elements explicitly "maxOccurs=1" and setting PersonLastName to "maxOccurs=1"

Owner: Mr. James Cabral
Status: Closed
Priority: High
Due Date: 08 Feb 2016

Comments
Mr. James Cabral 2014-07-15 05:29 UTC
use of case-specific elements beyond case initiation

use same messages

add new messages for case-specific elements for subsequent filings

hybrid - determine and separate element set required for initiation
Tags: Yes, Red, Purple

minOccurs

required or not

only workaround is to leave blank (assume nillable)

principles/rules to apply
Tags: Yes

Associations should be 1

AddressRepresentation should be 1

DateRepresentation should be 1

maxOccurs

this is the real problem

if set to 1

principles/rules to apply
Tags: Yes

indicators need to be 1

date representation needs to be 1

sequenceID elements should be 1

in general, dates and times should be 1

ECF routing IDs should be 1

MDELocationID

MDEProfileCode

SignatureProfileID

ServiceRecipientID

. . .

in general, amounts should be 1

"RoleOf" objects should be 1

Mr. James Cabral 2015-10-02 14:09 UTC
? There was much discussion on challenges with cardinality
? Many elements may typically occur only once, but that?s too restrictive when exceptions arise
? Conversely, making everything unbounded is too broad and may negatively impact interoperability
? Could also complicate things for developers who may need to allow for additional occurrences in situations that may not make sense in their implementation
? TC members generally agreed we should limit constraining elements, at least in situations where there?s any chance more than one occurrence may be needed
? TC members should review cardinality in new mapping spreadsheet

Mr. James Cabral 2015-11-10 20:15 UTC
Jim Harris will schedule a call to develop a recommendation for cardinality in ECF 5 and bring it back to the TC for approval

Referenced Items
OasisECFTC_LACOISABFeedback_20111003.docx (27K) 2011-10-10 Download | View Details
ECF-5-NIEM-mapping.xlsx (142K) 2014-07-14 Download | View Details
Schema_Cardinality_Issues_&_Options_v0.07.pptx (2MB) 2015-11-10 Download | View Details
Proposal for Resolution of the Cardinality Issue v2.doc (31K) 2016-01-29 Download | View Details


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