|
All: The group needs to address Harry McAllister’s concern regarding the _expression_ of validation rules. We concluded at the last meeting that many of the existing issues and future work are dependent on finding an agreement. Perhaps we can start this important discussion via this mailing list. The goal is to gather as much feedback as possible and opinions from everyone. This will be helpful for when have the discussion at next meeting (TBD – within 1 or
2 weeks) There are a couple of reference notes that can give you some background:
1.
Excerpt of the minutes from the December 2009 SC meeting: “Harry McAllister clarified that the issue for discussion doesn’t relate so much on the syntax of validation rules per se but rather to the scope of validation rules. The validation
WG has been attempting to express some quite complex algorithms and relationships and is running into difficulties because of the limitations of the syntax that has been adopted as a primary _expression_ of these rules. The point is not so much about the adoption
of a particular syntax but rather to the fact that the validation WG is in some cases attempting to implement rules which would already be the problems for any consuming system. Harry would like the group to make a decision as to whether such algorithms should even be in the scope of the Validation WG or whether we should restrict ourselves to simpler expressions. Andrew noted that we need to ensure the samples we provide are correct and complete. We should look into the possibility of using: - simpler expressions readily expressable in the XPath/XQuery syntax adopted by the group - more complex _expression_ which may have a natural language _expression_ but for which we don’t necessarily mandate a procedural _expression_.” 2.
Excerpt of the minutes from the last validation WG meeting (1/19): “Harry McAllister expressed some concerns (at the December 2009 Standards Committee meeting) regarding the technical _expression_ of validation rules, in particular limitations of the
chosen XPath technology.
-
Background: Over the past 1½ year, the validation WG reengineered the way validation rules are expressed in the specification and agreed to provide a natural English _expression_ and a technical (XPATH)
_expression_ for all validation rules. The problem is that some complex rules simply can’t be expressed using any particular syntax and that perhaps those rules should only have a natural/English _expression_ and forgo the technical _expression_.
-
àHarry McAllister was to send an open note to the group for discussion.
-
The group discussed the issue but felt more input from Harry was needed
o
Marc Addison noted XPATH was chosen as the natural implementation technology for XML.
o
Andrew Jacobs noted some rules can’t be easily or accurately expressed; and implementation technology is not powerful enough and too complicated to implement.
o
Andrew noted some open issues could be closed if the WG decided not to provide a technical/XPATH _expression_ for those rules that are too complex to express. Irina questioned how would the group make
the determination of whether a validation rules should have one or both representations.” What’s your take? How can we make validation rules better? Lyteck From: valwg@xxxxxxxx [mailto:valwg@xxxxxxxx]
On Behalf Of Lyteck Lynhiavu Attendees: ---------- - Marc Addison - Marc Gratacos, ISDA - Irina Yermakova, ISDA - Andrew Dingwall-Smith - Daniel Dui - Andrew Jacobs - Lyteck Lynhiavu, ISDA -
The information contained in either this email and, if applicable, the attachment, are confidential and are intended only for the recipient. The contents of either the email or the attachment may not be disclosed or used by anyone other than the addressee. If you are not the intended recipient(s), any use, disclosure, copying, or distribution is prohibited and may be unlawful. If you have received this communication in error, please notify us by e-mail at isda@xxxxxxxx <mailto:isda@xxxxxxxx> then delete the e-mail and all attachments and any copies thereof. This communication is part of an ISDA process and is not intended for unauthorized use or distribution. |