Code lists, parsers, and passes
I was reading about the Genericode work being done and started to get a bit worried. First, the theory of what they are doing is very good. The problem of how to create flexible, validatable, and extensible code lists has been a perennial problem for schema designers. None of the solutions tried have the feel of a "best practice".
What the Genericode folks are saying is that the code lists need to be handled differently. They need to have a design that will take the validation out of the role of the parser and into a second layer of validation. This second layer would be one in which management of code lists could once and for all have a best practice and meet all requirements (flexibility, validatability, and extensibility).
I have no problem with their identification of the problem nor their solution. The problem I had was wondering how my customers would react to the solution. I've heard consistently that they want the parser to do more and to do it in one pass. In short, put as much of the data structure integrity and validation workload on the parser in one pass. This goes against the trend toward two-stage validation as described by Genericode. I had a similar concern years ago when OAGIS proposed two -stage validation as a way to add additional restrictions onto a schema using the Schematron standard.
So I find myself in the unenviable position of liking the thinking behind these trends that are pulling workload away from the parser in order to solve some perennial problems. However, I hear from clients that they are interested in putting more workload onto the parser and would never go to the effort needed to do second stage validation.
Ultimately of course the clients decide for all of us, no matter if they are clients of an individual consultant or one of a large ERP vendor. I think there will need to be some real training before the marketplace will be ready to decide what is right and what is not. In the meantime, I hear a clear message from clients to make the parser do more work and not less.
What the Genericode folks are saying is that the code lists need to be handled differently. They need to have a design that will take the validation out of the role of the parser and into a second layer of validation. This second layer would be one in which management of code lists could once and for all have a best practice and meet all requirements (flexibility, validatability, and extensibility).
I have no problem with their identification of the problem nor their solution. The problem I had was wondering how my customers would react to the solution. I've heard consistently that they want the parser to do more and to do it in one pass. In short, put as much of the data structure integrity and validation workload on the parser in one pass. This goes against the trend toward two-stage validation as described by Genericode. I had a similar concern years ago when OAGIS proposed two -stage validation as a way to add additional restrictions onto a schema using the Schematron standard.
So I find myself in the unenviable position of liking the thinking behind these trends that are pulling workload away from the parser in order to solve some perennial problems. However, I hear from clients that they are interested in putting more workload onto the parser and would never go to the effort needed to do second stage validation.
Ultimately of course the clients decide for all of us, no matter if they are clients of an individual consultant or one of a large ERP vendor. I think there will need to be some real training before the marketplace will be ready to decide what is right and what is not. In the meantime, I hear a clear message from clients to make the parser do more work and not less.
posted by Paul at
4:04 PM
