Provide a schema generation api

[GoogleCodeExporter]

Downstream developers who make extensive use of schema report that they often 
make 'microschema's to govern particular cases. These may be statically or 
dynamically generated (static here means: depends upon the code the developer 
is writing, so in theory *could* be done with a schema resource; dynamically 
here means: depends on the content supplied by a user, and is generated on the 
fly for validation of information).

Also, for folks creating things that embed schema (like wsdl), there's a desire 
to be able to output this sort of information. Other APIs exist, but aren't 
particularly compatible with GenXDM.

There is an in-memory representation of schema components, in the bridgekit. 
Unfortunately, it doesn't have write/serialize functionality, and is quite 
difficult to use (it's designed to be driven by a schema parser written by a 
schema expert; it's really quite painful), and because it implements the schema 
model interfaces, it lacks document boundaries, imports, and the like.

Suggested resolution: provide a 'builder' style generator for a subset of 
schema components, avoiding the complexities that make the schema development 
chamber into a room full of corner cases. Something like this:

schemaDocument(targetnamespace)
import(targetnamespace)
include(location)
elementDefinition(name, type reference)
simpleType(name, base, collection<facets>)
complexType(name, model, attributegroupreference)
attributegroup(name)
attribute(name)

the 'model' in complexType, and the collection of facets in simpleType, might 
be done as other events. the point here: no substitution groups, avoid 
anonymous types, and so on. Support a simple, hard-to-screw-up subset of schema 
for generation; leave complex definitions to schema editors where folks have 
the time to develop really complicated stuff.

Side note: since we also support schema parsing from an XML model in memory, 
users who find the subset too restrictive can work around it by creating their 
own stuff that way. The builder will probably provide a method on the order of: 
void <N> build(FragmentBuilder<N> builder), and possible a void 
stream(ContentHandler handler).

This should either be a part of bridgekit (only not really; bridgekit *ought* 
to contain just the bits that bridge developers reuse) or a separate processor, 
or possibly attached to the existing schema parse processor.

Original issue reported on code.google.com by aale...@gmail.com on 22 Aug 2012 at 5:20

[GoogleCodeExporter]

Checking in the API. This is open to suggestions. The implementation isn't 
started.

Original comment by aale...@gmail.com on 6 Dec 2012 at 7:24

• Changed state: Started

[GoogleCodeExporter]

Will not be completed in 1.0. Defer to future.

Original comment by aale...@gmail.com on 24 Oct 2013 at 5:18

• Added labels: Milestone-Future
• Removed labels: Milestone-Release1.0