Introduction
 
“What standards do we need in e-learning?”  is a commonly debated topic. It should not be debated however without asking the opposite question; “Where do we need choice in e-learning?” Only through addressing both these questions, where we need standards and where we need choice, can we achieve desired results. 
 
Creating specifications for the emerging e-learning environment is complex. The complexity arises from several factors.
 
• Information technology is changing
• How we use technology in education is changing
• There are many stakeholders
• Educational software needs to integrate into wider IT environment
 
Goal & Vision
 
The ultimate goal is to create a learning technology environment that allows for tight integration as well as diversity. This requires carefully balancing the goals of interoperability and standardization with the competing goals of innovation and diversity. 
 
An Analogy
 
The field of law provides one analogy where these abstract goals are successfully balanced.  The US Constitution provides a broad set of laws, which apply to the whole country. It allows individual states to define additional laws that apply statewide. In turn, state law allows for municipalities to create additional local laws. The Constitution is by design a efficient and effective document. It only specifies what it needs to, and leaves open areas for variation. However, it does force states to agree with it and not pass conflicting laws. This creates a system where there is broad agreement over a limited set of things, but also locally defined laws. These local laws in different regions can be different and conflicting, as long as they adhere to the constitution. If the broader overarching rule set (Constitution) is created first, then the environment for creating local laws is clear. All that is required to create local rules is to assure that they are not in conflict with the Constitution. 
 
What’s most impressive about the U.S. Constitution is what it doesn’t say. If its framers had tried to put in more detail, it would have inevitably have had to change more often. Instead it remains a remarkably stable document.
 
Approaches
 
There are many approaches that work in solving complex problems. Sometimes a top down directed approach works well, other times an experimental bottom up approach is better. Sometimes utilizing both is required. In a problem space as large as eLearning the most efficient way to tackle the problem is not to dictate a particular approach, but to put all the resources and methods to bear in a coordinated way.
 
Another example of a complex system of law can be found in the European Union.  In the EU countries already had well-established laws, and much later a common set of rules were created. In this case, the problem was how to create overarching rules that had minimal conflict with the local rules already created. This approach, building practice over time and harmonizing afterwards, can lead to the same layered result. Which approach is more appropriate and efficient is an open question. 
 
Top down approach
 
Thinking through all of the issues of a system ahead of time would appear to be a faster approach, but doing so for a field as large and complex as eLearning would be impossible. However, the top-down approach adds value when it doesn’t dictate all the details, but puts some broad agreements in place. 
 
Gaining broad conceptual agreement, and subsequently refining it, is the fastest and surest way to success in areas as complex and with as diverse opinion as Law and eLearning. This winnowing process happens all the time in other contexts. The practice of parking issues when disagreements arise so that an agreement can ultimately be reached is a common practice. If something is preventing agreement it is set aside, to be dealt with later.
 
The critical factor is that when an agreement is reached it must be concrete. It should be documented in a way that is specific and unambiguous. It should state only what has been agreed to, and no more, as simply clearly as possible. 
 
Time is saved by concentrating on documenting what is common and document that, rather than listing all the differences. When an irresolvable difference is identified, it is set aside, to be handled in a subsequent phase. After an agreement is reached and documented the next phase can start. The discussion can break into Groups with similar points of view around “parked” issues can break into separate discussions to see if a more specific agreement can be reached. Each of these groups will use the same process: Agree on what’s common, document those commonalities, and, if needed, break into even smaller groups for separate more specific agreements. The trail of agreements that result will range from the general loose ones needed over a wide area to successive refinements for market segments, enterprises or other groups.
 
Degrees of Interoperability 
 
Interoperability is not binary. If it were, then there might be a single standard that everyone used. In a dynamic and diverse field such as e-learning this would be a mistake.  Instead there could be degrees of interoperability, which enables things to be interoperable in differing degrees.
 
Interoperability may start in pockets. An enterprise may achieve it among their systems. A market segment may achieve interoperability around a certain process, such as booking airline tickets. Although we would like to think that in future everything is interoperable, in practice it’s not so black and white. 
 
Interoperability is best viewed from a local perspective. As a user, you want all the things that you use regularly to be tightly integrated things infrequently done have less of a need to be interoperable. Therefore, there are gradations of interoperability; small pockets of tight interoperability as well as broad loose interoperability. This means, we can never enforce a universal solution, but must instead pursue a strategy of enabling varying degrees of interoperability.
 
Therefore, we will need both broad general specifications, which promote broad interoperability goals, as well as more localized constrained agreements to get tight integration in a specific community. This is similar to the scope of law example. Several sets of specifications need to be created, which need to align and cover differing scope. If we take the top down approach, i.e. create general rules first and then the variants, how might the process work?
 
Since we don’t know at the start how many layers of specifications we need, (federal, state, county, or just federal and city), how many iterations it might take to get from broad general agreement to the specific agreement needed for tight integration in a specific domain is unknown. It depends on the complexity of the domain and the variety of opinions.
 
It is a matter of finding the “sweet spot”, where there is an agreement, which is neither too general, nor too specific. There is a point where moving to be more specific; either makes the problem much more complicated or makes it less universal. At this same point, if you made the specification more abstract or general, you would not gain more applicability, such as acceptance in a wider community. If you’re in this general area, then you might be at a “sweet spot”. It is important to find a way to document the agreement reached at this “sweet spot” rather than trying to push further to a level, which makes it easier to document.  This is an important concept, since it is the problem domain, which determines where these “sweet spots” are located, and therefore the forms of documentation of agreement might not be universal among domains. 
 
How do we document the various forms of agreement?
 
There isn’t one answer to this question. Precisely documenting various forms of agreement is a tricky thing to do in practice for a couple of reasons. Most people find it’s easier to produce a precise specification, than to create a general one. That’s because there are not universally accepted ways of documenting conceptual agreement. For some specific things, such as data structures, there are tools which can easily document the agreement, but very abstract, conceptual notions are harder to document. Additionally, everyone can see the value of the specific thing, but don’t see the value of the general one. For example, a group might find it easier to agree on defining a data structure using XML Schema, then just producing a conceptual entity relationship model. However, it would be better is they just stuck to the latter: getting the general agreement first, before taking the next step of a more specific and precise binding. The value comes from gaining consensus, and creating better specific specifications in the future. Agreeing on the entities, their definitions, and their relationships, before specifying each individual field, might be a useful place to reach. Then a fallback position is documented so that in case things bog down, you are not back to square one.
 
Conversely, if we constrain ourselves to only documenting agreements a certain way, for example, as XML schemas, then only certain types of agreements that can be documented. It would be better to look for alternative forms of documenting agreements than forcing them to match the tools we have. Documenting assumptions, definitions, and conceptual data models may be more appropriate in certain circumstances.
 
There is a certain engineering and technical mindset, which equates more detail with better. Here every detail must be known and getting a complete solution is the goal. This runs contrary to the method described, and needs to be explicitly guarded against.
 
Another point to raise here is that “testing” for general agreement is a low cost step. If one assumes that everyone agrees about certain things, it is easy to test and document this. The only reason it might be hard, would be in the case where there was not the expected agreement. In this case it is still more efficient to find out sooner, than after work has proceeded under the wrong set of assumptions.
 
There are some questions that could be asked which might only expose diversity. For example, asking if a certain action always happens atomically or in batch is bound to yield both answers. This has the tendency to exponentially complicate the agreement. Concentrating on just what is done rather than how helps avoid these complications.
 
Conclusion
 
The overall point is that we need to continue to ask questions and test assumptions as we proceed, and resist the temptation to latch onto a particular mechanism even if it is at hand and easily agreed, until we’ve ascertained that it brings us closer to our real objective. We still need to get to specific bindings in order to achieve interoperability, but we might not want to do this as a single step. Agreements about concepts, data structures, service definitions and protocols are all needed to reach the ultimate goal, but taking measured steps to get there might be the quickest way.