[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: ECF 4.01 Constraint Schemas
|
Jim – First, let me apologize up front as some of this may seem to rehash thoughts that have already been shared. I’m just trying to think through implications of
various options. The easy part . . . It appears there is agreement that a full review of cardinalities is needed, and that such a review should be included in the scope of work
on ECF 5. With no dissent from other members of the TC, I think we all agree we should go ahead and add that task to the ECF 5 plan. Regarding 4.01, Jim C noted the constraint schemas do indeed reflect intended cardinalities. I understand from earlier messages that Arizona’s implementation
started with 4.0, which unintentionally included unbounded elements as a result of transformation failures when constraint schemas were generated. Since this has become an issue, I’m assuming it’s Arizona’s goal to be able to validate against 4.01 without
having to deal with cardinality constraint violations that are a direct result of the aforementioned inconsistencies between 4.0 and 4.01. Is that a valid assumption? The solution you proffer, understandably, would be to roll back to the unbounded elements (i.e., not applying the intended constraints). Doing so would not
likely impact 4.01 implementations in that constraints would be relaxed (not further constrained). I suppose this could conceivably create a problem if an instance contains more occurrences than would be logical for the affected transaction. Seems like that
would be highly unlikely and, even if it did occur, probably wouldn’t break anything. That said, it would seem more appropriate to only relax constraints on those elements that Arizona really needs unbounded. You apparently have valid use cases that would
require these changes anyway. Can you share specifically which elements are affected (i.e., those that need to be unbounded or at least less constrained)? Since the current version of the spec reflects original intentions, it would seem more dutiful on the
part of the TC to change only those elements for which a need has been determined rather than unbounding the
200+ affected elements. I think what I’m trying to say is that we appreciate and understand what you’re saying and, given the circumstances, would like to strike a balance that meets
Arizona needs while still carrying out original intentions of the TC. Understanding the specifics would also further efforts of the review task in ECF 5. So is there a way to identify which elements are impacted? Jim H From: Price, Jim [mailto:JPrice@courts.az.gov]
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]