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: Re: ECF 4.01 Constraint Schemas


Jim Price,

If I understand your comments, you are suggesting that

  1. The TC does not address this in the upcoming errata to the OASIS 4.01 standard.
  2. The TC discuss whether the TC should update the constraints in a (currently unplanned) 4.02 minor version or the planned 5.0 major version?

If that is correct, based on Jim Harris’ comments and the lack of other responses, I think we have a consensus that this is how we should proceed.

  thanks,

--
Jim Cabral
502-509-4532

From: Price, Jim
Sent: ‎Friday‎, ‎April‎ ‎25‎, ‎2014 ‎2‎:‎50‎ ‎PM
To: Jim Harris, James E Cabral, legalxml-courtfiling@lists.oasis-open.org

The preferred approach from this implementer’s perspective is to honor the constraints contained in the 4.0 draft spec (option 2).  Arizona’s implementation, which is four years in the making, is based on the draft 4.0 spec.  Additionally, it is reasonable to assume that implementers new to LegalXML – who were either unfamiliar with the version 3.0 spec or the subsequent 3.0 update considerations/discussions that are believed to have occurred – would have based their development efforts on the 4.0 draft spec.  With all due respect to the TC, the fact that an oversight is believed to have occurred sometime between versions 3.0 and 4.0, while unfortunate, is immaterial.  At this time, I suggest either revisiting the constraints for the 5.0 spec or in an interim 4.02 spec.

 

Sincerely,

 

Jim

 

From: legalxml-courtfiling@lists.oasis-open.org [mailto:legalxml-courtfiling@lists.oasis-open.org] On Behalf Of Harris, Jim
Sent: Monday, April 21, 2014 11:05 AM
To: James E Cabral; legalxml-courtfiling@lists.oasis-open.org
Subject: [legalxml-courtfiling] RE: ECF 4.01 Constraint Schemas

 

At this stage, option 1 probably makes the most sense.  As long as we do revisit, as you’ve already noted, constraints in ECF 5 (at the very least elements implementers needed to be unbounded - or something more than 1).  In the meantime, how problematic will this be for ECF 4.01 implementers?  Are we requiring extensions (and impacting interoperability), where they typically should not be required?

 

 

From: legalxml-courtfiling@lists.oasis-open.org [mailto:legalxml-courtfiling@lists.oasis-open.org] On Behalf Of James E Cabral
Sent: Monday, April 21, 2014 12:34
To: legalxml-courtfiling@lists.oasis-open.org
Subject: [legalxml-courtfiling] ECF 4.01 Constraint Schemas

 

ECF TC:

 

At the April ECF TC meeting, we discussed the issue of a change to the constraint schemas that occurred between the CSPRD01 and CSPRD02 versions of the ECF 4.01 specification.  As a result of that change, most of the elements in the NIEM subset changed from maxOccurs=”unbounded” to maxOccurs=”1”.  Since we had, at that time,  not been able to find documentation that this change was intentional, the TC decided at the April meeting to fix the constraint schemas back to the default of maxOccurs=”unbounded”. 

 

In an attempt to reverse the schemas, I have discovered the source of the change and now belief the constraints were intended all along.  Since the ECF 3.0 days, we have used a set of XSL transforms to generate the constraint schemas from the NIEM subset schemas - the transforms are distributed in the specification included in the constraints folder.  Apparently, in ECF 4.0 and  the CSPRD01 version of ECF 4.01, the transforms failed to apply the intended updates to the subset schemas, leaving them unconstrained.  The transforms themselves have not been changed significantly since ECF 4.0.  Since CSPRD02, the constraints have simply been applying the constraints as originally intended. 

 

I see 2 options for moving forward:

 

  1. Accept the transforms, and resulting constraints since CSPRD02, as normative, make no further changes to the constraint schemas in ECF 4.01.
  1. Decide to forgo all constraints in the NIEM subset of ECF 4.01 and use the subset schema as the constraint schema as we did (unintentionally) in CSPRD01.

 

In either case, we need to revisit our approach to constraints in ECF 5.0.

 

I support option 1.

 

Thoughts?

 

--
Jim Cabral
502-509-4532

 



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