Comments on alternative schema and on examples

explicitness
- The alternative schema used in this VOTable aims to be very explicit. Tries to use vocabulary form VO-DML for the elements
used in annotations. Note that this not means that a model can be inferred as the annotation may not be complete, and
it may not be possible to infer inherited roles for example. 

element vs attribute
- Should we use attributes for TYPE and ROLE iso ?
- LITERAL is kept rather close to PARAM, i.e. all data represented by XML attributes for example (apart from TYPE).

proxy objects
- use case in test4 where the name of a filter is used as an FK in a column in a table. This is a particular implementation of a foreign key,
but the actual referenced objects are not in a table but in the set of global instances. These really also are mere "proxies"
to the actual object that is represented and could be a remote reference. Should this pattern, where a simple string is used to
refer to an object proxying for a remote object be formalized?
- note, currently the reference is annotated as a ORMReference, though the target is not in a table. It might be possible to use
and IDREF here ("GROUPref") if we allow its value to be a FIELDREF. IF we consider DATA to be given, only annotations
can be added, there is no guarantee that such fields can be (uniquely) used as IDs in the VOTable doc.
We could provide but this may not always be appropriate.
 
collections of globals
- do we want to allow subsets of the globals to be gathered in collections? If these were given their own ID this might
help in the ORM-like reference to the objects inside, as their CONTAINERID can be set. The definition of these collections
might not have to be based on the type of the members. For example SDSS filters could be in a separate collection of 2MASS filters.


CONTAINER reference
- the schema uses an explicit CONTAINER to represent a reference to the container for objects that are not explicitly embedded
in their parent. This is modeled as a VODMLReference. However it should not need a ROLE (was actually introduced to completely 
remove dependency on vodml-map model. For this reason ( and this reason only) VODMLRole's ROLE element is given minOccurs=0.
OK? It means the rule that the explicit roles need a ROLE must be enforced elsewhere (add schematron to VOTable?)
NB *if* at some point we start modeling storing objects over multiple tables, e.g. by mapping inheritance "vertically" 
(e.g. https://docs.oracle.com/cd/E13189_01/kodo/docs341/ref_guide_mapping_classmapping.html#vertical), we may need an EXTENDS
reference from the child table to the parent which would also not need a ROLE.

 
 ISSUES:
 - should we have single type for structured instances, say SINSTANCE, intead of VODMLOBJECT and SVALUE.