[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: ECF 4.01 Constraint Schemas
Jim Cabral, After reviewing your response and re-reading the two options, I’m concerned that they both seek to achieve the same outcome. Permit me respond to you in kind.
Regards, Jim Price From: legalxml-courtfiling@lists.oasis-open.org [mailto:legalxml-courtfiling@lists.oasis-open.org] On Behalf Of James E Cabral Jim Price, If I understand your comments, you are suggesting that
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, -- From: Price, Jim 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 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 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:
In either case, we need to revisit our approach to constraints in ECF 5.0. I support option 1. Thoughts? -- |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]