sshyran / genxdm

Automatically exported from code.google.com/p/genxdm
0 stars 0 forks source link

Add validation methods to typed context #43

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
Although we have effectively created a base untyped immutable API, we have in 
the process lost the ability to produce typed trees.

There is very little point in having a typed API, if there is no way to produce 
the trees that that API manipulates.

There are three ways of producing a typed tree:

1) SequenceBuilder -- note that this still works (and is the only thing that 
works; legacy tests that depend on type information probably rely upon trees 
created programmatically via sequencebuilder)

2) parsing -- this might work to produce typed trees, if we passed a 
sequencebuilder instead of a fragmentbuilder to the document processor.  
However, in general, we want to make validate-on-parse a simple process 
(TypedDocumentParser? not clear how best to achieve), so that someone can 
implement efficiencies without being forced to learn internals of a particular 
processor or to break out of the standard APIs.

3)  from an existing tree in memory -- this tree may already be typed, or 
validated previously and modified since, or built from an infoset, or parsed 
without validating.  Regardless, we want a single, simple, obvious method to 
validate the tree, on TypedContext, probably something like:

N validate(N source, SequenceHandler validator, String schemaIdentifier)

Now, we can argue for a URI instead of a string, and calling it a 
schemaNamespace instead of 'identifier', and in general the contract for the 
method-argument equivalent of xsi:schemaLocation is debatable.  The method 
itself should have the characteristics: is not required to return the original 
source tree, but may do so. Uses the schemas already registered with the 
TypedContext (which is-a Schema).

We may wish to define a subinterface of SequenceHandler to be a 
SchemaValidator; such a subinterface would, like the relationship between 
contenthandler and fragmentbuilder, provide a standard means of accessing 
validation information as well.

Note that the javax.xml.validation interface assumes that a validator is 
associated with (even emergent from) a single "schema" (it conflates schemas 
and rng patterns, note).  That's less common for the APIs from whence gXML and 
then GenXDM grew, though it has a nice consequence: you can't end up 'unable to 
find the schema' that you need to use to validate.

Original issue reported on code.google.com by aale...@gmail.com on 24 Jan 2011 at 7:08

GoogleCodeExporter commented 8 years ago

Original comment by aale...@gmail.com on 31 Mar 2011 at 5:18

GoogleCodeExporter commented 8 years ago
Okay.

We're in process, at this point.  I don't know how much progress I ought to 
mark, here.

I've added the validate method.  I've also added a new interface, Validator.  
That interface allows you to set the schema cache, the exception handler (right 
now it's using SchemaExceptionCatcher rather than SchemaExceptionHandler, 
though, which is questionable), and the SequenceBuilder.  The idea is that you 
pass the validator, with the exception handler set, to the context, which sets 
the cache (to itself) and the builder (to its own builder).  Maybe needs more 
thought.  Not sure; this is a first pass.

Also, document handler has grown two new methods: setValidating and 
isValidating.

Once this all gets (properly) implemented, we should see the ability to create 
properly typed trees and stuff.

Original comment by aale...@gmail.com on 4 Apr 2011 at 6:22

GoogleCodeExporter commented 8 years ago
The methods that are there are not tested, but they're good enough.  We have 
both parsing and tree validation conceptually enabled, and there does not seem 
to be a major issue with the APIs defined (they may be refined, and they have 
to be implemented, but the core seems acceptable).

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

GoogleCodeExporter commented 8 years ago

Original comment by eric%tib...@gtempaccount.com on 30 Jul 2012 at 8:53