[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: ECF 4.01 Constraint Schemas
Jim H, Gary Graham and I sent the attached to the TC back on April 1, 2014 in response to Jim C’s “is the juice worth the squeeze” question. For your convenience, I am also attaching the constraint gaps that Gary documented. A word of caution. Having gone through a recent procurement process, it is evident from some of the sample LegalXML messages vendors provided that the newly rediscovered constraints will break their respective implementations. While the attached documents reflect Arizona’s concerns, we highly recommend exercising due diligence by polling vendors and other implementers to see how they might be impacted by the newly rediscovered constraints. Additionally, we have no idea at this point in time if there exist other element constraints that we haven’t yet used that will cause problems for us in the future. Recommendation: Unless it is blatantly obvious that an element should be constrained, it should be left unbounded. Let the implementer decide how best to approach his/her problems/opportunities, i.e., let business requirements dictate the technical solution when/where possible. IMHO, the best way to do this with respect to our LegalXML specs is to make them flexible enough to adapt to differing business needs. Sincerely, Jim From: Harris, Jim [mailto:jharris@ncsc.org] 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? -- |
Attachment:
ECF 4-0 to 4-01 Squeeze Points.docx
Description: ECF 4-0 to 4-01 Squeeze Points.docx
Attachment:
ECF 4-0 to 4-01 Differences-1.docx
Description: ECF 4-0 to 4-01 Differences-1.docx
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]