Sm* classes should be independent of the underlying instance representation

[GoogleCodeExporter]

Classes such as SmElement<A> use the A parameter to align the values of 
constraints with the underlying tree model, such as when storing a minimum and 
maximum constraint on an integer value.

This means that validating the data from the underlying tree model will go 
faster, as it won't be necessary to compile to the particular tree model's 
representation. It does so, however at a cost of early binding an in-memory 
representation of a schema, when late binding is appropriate.

Three obvious possible paths to resolve this:

a new Sm* representation should have some sort of "bind" API that returns the 
current representation that is specific to a particular atom binding.
A "prepare" call, and the schema representation stores all atom bindings that 
it has needed to store.
The schema model has a single known representation, and the bridge 
implementation for a particular tree must be able to compare with the known 
representation, whether or not it uses that representation itself.
Not sure which is the best approach.

Original issue reported on code.google.com by aale...@gmail.com on 12 Oct 2010 at 4:36

• Blocking: #63

[GoogleCodeExporter]

Issue 62 has been merged into this issue.

Original comment by aale...@gmail.com on 2 Jun 2011 at 5:40

[GoogleCodeExporter]

The branch afreesm shows an attempt to disentangle.  We'll see how it goes.

Original comment by aale...@gmail.com on 2 Jun 2011 at 5:41

• Changed state: Accepted

[GoogleCodeExporter]

Update.  ValueConstraint is one of the places that is going to need some work.  
It's the "fixed/default" value constraint.  In order to work without a member 
representing the variable (just the lexical representation), it will need to 
have access to an atom bridge *and* to something that indicates what method to 
call on the atom bridge.

A number of other interfaces or classes have 'validate' methods taking a list 
of atoms.  We can move the signature from the class/interface to the method 
easily enough, but we'll need to look at the implementations to understand what 
is needed to identify the atoms at validation time.

Original comment by aale...@gmail.com on 2 Jun 2011 at 6:37

[GoogleCodeExporter]

Interesting.

The two most problematic abstractions are Limit and ValueConstraint, both of 
which are expected to contain precompiled values against which other typed 
values can be checked.  In both cases, the solution is to store the type of the 
constrained value, the lexical value (rather than the compiled one), and to 
pass the necessary tools to compile the lexical ones at validation time.

Probably.

As it stands, I've been able to hack <A> out of a lot of places, including the 
MetaBridge (note that we have getAtomBridge on every available surface, which 
is pretty damned pointless).  The bridges don't seem to mind losing this stuff. 
 Now ... bridgekit is going to be nightmarish, and that's even before we get to 
the problem of the schema parser and validator.  We'll see what happens, I 
guess.

Original comment by aale...@gmail.com on 2 Jun 2011 at 7:46

[GoogleCodeExporter]

XMLSchemaParser, in proc-w3cxs impl, is another place where the removal of A 
(particularly of AtomBridge) causes some problems.  Probably need to open a new 
issue to fix it up; see the TODOs in the code.  Basically, in a number of 
places, the atom bridge was used to validate schema primitive types (probably 
unwise, in any event, as there's no way of telling whether the atom bridge 
implementation is correct per spec, from inside the schema parser).

Original comment by aale...@gmail.com on 6 Jun 2011 at 2:32

[GoogleCodeExporter]

SchemaConstraintChecker is a bloody mess.  Another new issue there, I believe.  
Now the solution looks something like "canonicalatombridge", an implementation 
of AtomBridge found and used only in the parser.

Original comment by aale...@gmail.com on 6 Jun 2011 at 3:08

• Changed state: Started

[GoogleCodeExporter]

Original comment by aale...@gmail.com on 6 Jun 2011 at 3:28

[GoogleCodeExporter]

Closed at r226.  Issue 63 opened.  We need another issue for validator fixup, 
though.

Original comment by aale...@gmail.com on 7 Jun 2011 at 12:28

• Changed state: Fixed