TypedContext shouldn't extend Schema

[GoogleCodeExporter]

While Schema looks to be a perfectly good interface, it is a specific kind of 
interface for a specific kind of way of manufacturing a schema incrementally. 
Other ways might exist, like simply parsing a schema from a file directly, 
without incrementally building it up via this particular interface.

What type TypedContext might need, if anything, is a specific way of *reading* 
schema information from some sort of Schema object (SchemeCache). It would 
appear that "Schema" is an interface for one way of constructing objects for 
such a cache, but possibly not the only one.

Suggestion - simply remove the "Schema" interface from the hierarchy of 
TypedContext.

Original issue reported on code.google.com by eric%tib...@gtempaccount.com on 25 May 2011 at 12:31

[GoogleCodeExporter]

"Suggestion - simply remove the "Schema" interface from the hierarchy of 
TypedContext."

Not gonna happen.  Replace it with something else, perhaps (ComponentProvider 
is a possible, but we need the register() method as well in order to add 
components).

I'm not at all clear on what it is that provides for "manufacturing a schema 
incrementally".  register()?  If so, then I'm adamantly opposed to this 
suggestion.  "Schema" is a misnomer, in any event; what the so-named interface 
represents is a collection of schema components, which may or may not belong to 
one namespace (which is how a single 'schema' might best be defined).  
"SchemaCollection" or "SchemaCache" would be better descriptions.

I'm also not in favor of making the already-opaque typed API more opaque by 
removing the register() method and thus the only advertised functionality to 
provide components to the processing context.

Original conception of TypedContext (then called GxProcessingContext): a 
factory and accessor for abstractions (like Model and FragmentBuilder), a 
registry for processors, and a registry for schema components, all tied to a 
set of specialized parameters including N and A.  We've already removed the 
entanglement with processors; applications don't need us to help them associate 
processors with a cache of schema components, and processors in our world are 
quite able to be shared among contexts for different bridges.  It is possible, 
if we could divorce org.genxdm.xs from <A>tom, that the notion of a schema 
component collection shared among a processing pipeline could be distinguished 
from the notion of a factory and accessor for abstractions specialized on N and 
A (a bridge).

But if we were to achieve that point, we'd probably be asked to add an API to 
as a registry for schema component caches.  Really, the need to have these 
components available throughout the processing lifetime is the original reason 
for naming the abstraction "ProcessingContext".  We have less reason for 
calling the base abstraction a ProcessingContext (inertia, mostly); it might 
better be described as "NodeBridge".  TypedContext - Schema is 
NodeAndAtomBridge.  The 'Schema' (mid-to-long-term collection of schema 
components used by an application or applications or collection of processors) 
*is* the 'context' in which operations occur.

Validation can't happen without the schema component collection.  We haven't 
yet got validation working at the level of ease that it ought to be, mind, but 
complicating it at this stage doesn't strike me as a win.

So ... I need to know why this is a 'specific kind of interface for a specific 
[means] of manufacturing [schema components from one or more schemas] 
incrementally.'

Note that, so far as I am aware, the only way (currently) to create the 
components which are supplied via register() is to parse a schema from a file 
(or other URL) directly.  There is no "mutable schema" processor anywhere.

Original comment by aale...@gmail.com on 25 May 2011 at 12:50

[GoogleCodeExporter]

Following some refactoring of the typed interface hierarchy, such that Schema 
no longer is-a ComponentProvider or ComponentBag, and instead has-a 
ComponentProvider and ComponentBag, but MetaBridge now is-a Schema, it makes 
more sense to remove this.

The change will mean that instead of calling 
TypedContext.getTypeDefinition(args) (old-style), or 
TypedContext.getComponentProvider.getTypeDefinition(args) (current style), 
you'll call TypedContext.getMetaBridge().getComponentProvider().  MetaBridge 
becomes the entry point for type information (and should probably be called 
"TypeBridge"; that whole "meta" thing is just confusing).

This may or may not happen before the next release.

Original comment by aale...@gmail.com on 9 Jun 2011 at 7:26

• Changed state: Accepted

[GoogleCodeExporter]

grr.  i need to be the owner.

Original comment by aale...@gmail.com on 9 Jun 2011 at 7:27

[GoogleCodeExporter]

This issue was closed by revision r279.

Original comment by aale...@gmail.com on 12 Oct 2011 at 6:38

• Changed state: Fixed